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(57) Abstract: The invention relates to mobile messaging and 
presence services. According to one aspect of the invention, a 
client device of the mobile messaging system adds a qualifier to 
a presence attribute, the qualifier comprising one or more param- 
eters specifying the use of the attribute. A client device receiving 
a presence attribute processes the received presence attribute ac- 
cording to the qualifier parameters in said received attribute. An- 
other aspect of the invention is the showing of how to assemble 
and store presence items with names, attributes and values in a sin- 
gle presence set within a role having an associated authorization 
group of members that have the right to subscribe to the whole or 
part of the presence set of the same role. 
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Mobile Instant Messaging and Presence Service 
Background of the Invention 

The present invention relates to messaging in mobile telecommunica- 
tion systems and more particularly to presence attributes in a mobile instant 

5 messaging and presence service. 

An instant messaging service provides the end users with a means 
for fast, interactive, mainly text-based communication. The utility of instant mes- 
saging is greatly enhanced by the addition of a service that will keep track of the 
online status and availability of your chat partners or "friends"; as well as notify 

10 you of changes to their status or availability. This type of service is called a 
"presence service". In general, presence can be considered containing various 
dynamic information on a user or client connected to the instant messaging ser- 
vice via various means. Examples of this information is reachability, availability 
and location of the user for communication. The combination of instant messag- 

15 ing and presence services is called an instant messaging and presence sen/ice 
(IMPS). This kind of service has been available for wireline Internet users but 
the interconnectiv'rty between wireline users and mobile users has been missing. 

Wireless Village initiative has-been established to define specifica- 
tions for mobile instant messaging and presence service. The Wireless Village 

20 Instant Messaging and Presence Service (IMPS) includes four primary feature?: 
presence, instant messaging, groups and shared content. Shared content allows 
users and operators to setup their own storage area where they can post pic- 
tures, music and other multimedia content while enabling the sharing with other 
individuals and groups in an IM or chat session. The Wireless Village initiative 

25 enables both operators and end-users to create and manage groups. Presence 
is the key enabling technology for the Wireless Village initiative. In the existing 
Internet-based instant messaging service, the presence values are usually very 
simple, such as user is active, absent, not willing to communicate etc. These 
values are selected from the predefined sets of values. A white paper has been 

30 published on the Wireless Village mobile IMPS solution: "Wireless Village, The 
Mobile IMPS lnitiative:White Paper, dated on 26 th April 2001. The existing mo- 
bile terminal can be considered a personal tool which reflects the personal 
status more accurately than a desktop computer. Considering the wide range of 
information that may be obtained from the user and the mobile terminal, the an- 

35 ticipation of the presence information domain is very difficult. Thus a mechanism 
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should be developed to enable easy usage and addition of new types of pres- 
ence information. 

v 

Disclosure of Invention 

An object of the invention is to provide a solution for creation of new 
5 presence attributes besides already determined presence attributes. 

Another object of the invention is to show how to organize and store 
presence attributes for use by clients. 

According to a first aspect of the invention, a client device of a mobile 
messaging system adds a qualifier to a presence attribute, the qualifier compris- 
10 ing one or more parameters specifying the use of the attribute. A client device 
receiving a presence attribute processes the received presence attribute accord- 
ing to the qualifier parameters in the received attribute. A presence attribute is a 
collection of data describing presence information on a certain user and/or a cli- 
ent device, the presence information intended for other users. A presence at- 
15 tribute may also contain information for machine-to-machine communication be- 
tween the client devices. 

In further accord with the first aspect of the present invention, a mo- 
bile messaging system comprising at least one client device and a server, 
wherein the client device comprises means for transmitting presence information 
20 as presence attributes to the server and means for receiving presence attributes 
from the server, the presence information being categorized by a plurality of 
presence attribute types identified by attribute name, and the server comprises 
means for maintaining presence information based on the received presence at- 
tributes, is characterized in that the client device comprises means for adding a 
25 qualifier to a presence attribute, the qualifier comprising one or more parameters 
specifying the use of the attribute, and the client device comprises means for 
processing a received presence attribute according to the qualifier parameters in 
the received attribute. 

According to a second aspect of the invention, the client device com- 
30 poses presence information attributes that are identified by a combination of an 
authorizer, an attribute name and a qualifier, wherein the authorizer specifies 
the body responsible for maintaining the attribute and the qualifier specifies the 
use of the attribute. When receiving a presence attribute, the server and the cli- 
ent device search for already stored attributes containing same identifiers as the 
35 received attribute. An attribute already stored is replaced with the received at- 
tribute if the combination of identifiers of the received attribute is identical to that 
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of the already stored attribute. Otherwise the received attribute is added without 
replacing any previous attribute. 

In further accord with the second aspect of the present invention, a 
mobile messaging system comprising at least one client device and a server, 

5 wherein the client device comprises means for transmitting presence information 
as presence attributes to the server and means for receiving presence attributes 
from the server, the presence information being categorized by a plurality of 
presence attribute types identified by attribute name, and the server comprises 
means for maintaining presence information based on received presence attrib- 

10 utes, is characterized in that the client device comprises means for composing 
a presence information attribute identified by a combination of an authorizer, an 
attribute name and a qualifier, the authorizer specifying the body responsible for 
maintaining the attribute and the qualifier specifying the use of the attribute, the 
server comprises means for searching for an already stored attribute containing 

15 same identifiers as a received attribute and means for replacing the already 
stored attribute with the received attribute if the combination of identifiers of the 
received attribute is identical to that of the already stored attribute or otherwise 
adding the received attribute, and the client device comprises means searching 
for an already stored attribute containing same identifiers as a received attribute 

20 and means for replacing the already stored attribute with the received attribute if 
the combination of identifiers of the received attribute is identical to that of the 
already stored attribute or otherwise adding the received attribute. 

In further accord with the first and second aspects of the present in- 
vention, the system is characterized in that the client device comprises means 

25 for specifying in the qualifier the presentation settings of the attribute, and the 
client device comprises means for presenting the received attribute on the basis 
of the qualifier. 

In still further accord with the first and second aspects of the present 
invention, the system is characterized in that the client device comprises means 
30 for specifying in the qualifier the application to which the attribute should be ad- 
dressed, and the client device comprises means for addressing the received at- 
tribute to the application indicated by the qualifier. 

Still further in accord with the first and second aspects of the inven- 
tion, the system is characterized in that the server comprises means for deter- 
35 mining on the basis of the qualifier whether to send the attribute to one or more 
client devices. 
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According further to the first and second aspects of the invention, the 
system is characterised in that the presence attributes received from the client 
device by the server are stored in a database according to a publisher user in 
association with a presence group. 
5 In accordance still further to the first and second aspects of the inven- 

tion, the system is characterized in that each presence attribute is part of an 
item including an attribute name element and an attribute value. The name ele- 
ment may include an authority string indicative of an authority responsible for 
keeping the name element and attribute value unique. 
10 According still further to the first and second aspects of the present 

invention, the system is characterized in that a presence set comprises one or 
more presence attributes belonging to a single publisher role of a publisher user 
in association with a single presence group. 

In still further accord with the first and second aspects of present in- 
15 vention, a mobile messaging system is characterized in that a user of the client 
device as a publisher is able to use the client device or more than one client de- 
vice in more than one publisher role. 

According to a third aspect of the present invention, a mobile client 
device for mobile messaging systeriirthe client device comprising means for 
20 transmitting presence information as presence attributes to a server, the pres- 
ence information being categorized by a plurality of presence attribute types 
identified by attribute name, is characterized in that the client device further 
comprises means for adding a qualifier to a presence attribute, the qualifier 
comprising one or more parameters specifying the use of the attribute. 
25 According to a fourth aspect of the present invention, a mobile client 

device for mobile messaging system, the client device comprising means for re- 
ceiving presence attributes from a server, the presence information being cate- 
gorized by a plurality of presence attribute types identified by attribute name is 
characterized in that the client device further comprises means for adding a 
30 qualifier to a presence attribute, the qualifier comprising one or more parameters 
specifying the use of the attribute, and means for processing a received pres- 
ence attribute according to the qualifier parameters in the received attribute. 

According to a fifth aspect of the present invention, a mobile client 
device for mobile messaging system, the client device comprising means for 
35 transmitting presence information as presence attributes to the server, and 
means for receiving presence attributes from the server, the presence informa- 
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tion being categorized by a plurality of presence attribute types identified by at- 
tribute name, is characterized in that the client device further comprises means 
for composing a presence information attribute identified by a combination of an 
authorizer, an attribute name and a qualifier, the authorizer specifying the body 

5 responsible for maintaining the attribute and the qualifier specifying the use of 
the attribute, means for searching for an already stored attribute containing 
same identifiers as a received attribute, and means for replacing the already 
stored attribute with the received attribute if the combination of identifiers of the 
received attribute is identical to that of the already stored attribute or otherwise 

10 adding the received attribute. 

According further to the third, fourth and fifth aspects of the present 
invention, a mobile client device is characterized in that each presence attribute 
is part of an item including an attribute name element and an attribute value. 
The name element may include an authority string indicative of an authority re- 

15 sponsible for keeping the name element and attribute value unique. 

In further accord with the third, fourth and fifth aspects of the present 
invention, the mobile client device is characterized in that a presence set com- 
prises one or more presence attributes belonging to a single publisher role of a 
publisher user in association with a single presence group. ? 

20 In still further accord with the third, fourth and fifth aspects of the pre- 

sent invention, the mobile client device is characterized in that a user of the mo- 
bile client device as a publisher is able to use the client device or more than one 
client device in more than one publisher role. 

According to a sixth aspect of the present invention, a server for a 

25 mobile messaging system, the server comprising means for maintaining pres- 
ence information based on received presence attributes, the presence informa- 
tion being categorized by a plurality of presence attribute types identified by at- 
tribute name, is characterized in that the server further comprises means for 
searching for an already stored attribute containing same identifiers as a re- 

30 ceived attribute, and means for replacing the already stored attribute with the 
received attribute if the combination of identifiers of the received attribute is 
identical to that of the already stored attribute or otherwise adding the received 
attribute. 

In further accord with the sixth aspect of the present invention, the 
35 server is characterized in that the presence attributes received from a client de- 
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vice by the server is stored in a database according to a publisher user in asso- 
ciation with a presence group. 

In still further accord with the sixth aspect of the present invention, 
the server is characterized in that each presence attribute is part of an item in- 
5 eluding an attribute name element and an attribute value. The name element 
may include an authority string indicative of an authority responsible for keeping 
the name element and attribute value unique. 

Still further in accord with the sixth aspect of the present invention, 
the server is characterized in that a presence set comprises one or more pres- 
10 ence attributes belonging to a single publisher role of a publisher user in asso- 
ciation with a single presence group. A user of a client device in communication 
with the server acting as a publisher is able to use the client device or more than 
one client device in more than one publisher role. 

According to a seventh aspect of the present invention, a presence 
15 system, comprises at least one physical device having at least one presence cli- 
ent for enabling a presence user to interact with the system as a publisher or a 
subscriber, and a server for maintaining valid values of presence sets of attrib- 
utes of a publisher for access by subscribers according to associated presence 
groups. 

20 In further accord with the seventh aspect of the present invention, a 

presence system is characterized in that each attribute is part of an Item includ- 
ing an attribute name element and an attribute value. The name element may 
include a qualifier having information related to attribute usage. The name ele- 
ment may include an authority string indicative of an authority responsible for 

25 keeping the name element and attribute value unique. 

In still further accord with the seventh aspect of the present invention, 
the presence system is characterized in that a presence set comprises one or 
more attributes belonging to a single publisher role in association with a single 
presence group. The user interacting with the system as a publisher is able to 

30 use the presence client or more than one presence client in more than one pub- 
lisher role. Each attribute may be part of an item including an attribute name 
element an attribute value. 

Still further in accord with the seventh aspect of the present invention, 
the at least one physical device is a mobile physical device. 

35 According to an eighth aspect of the present invention, a computer 

program embodied in a computer-readable medium for storage in a physical de- 
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vice, is characterized in that the program is a presence client program for ena- 
bling a presence user to interact with a presence system as a publisher of at 
least one presence set of attributes for access by one or more subscribers ac- 
cording to an associated at least one presence group. 
5 In further accord with the eighth aspect of the present invention, the 

presence client program is characterized in that the program enables a pres- 
ence user to interact with the presence system as a subscriber to at least one 
set of attributes associated with a presence group in which the subscriber is a 
member. 

10 In still further accord with the eighth aspect of the present invention, 

the presence client program is characterized in that each attribute is part of an 
item including an attribute name element and an attribute value. The name ele- 
ment may include a qualifier having information related to attribute usage. 

According further to the eighth aspect of the present invention, the 

15 presence client program is characterized in that the name element includes an 
authority string indicative of an authority responsible for keeping the name ele- 
ment and attribute value unique. 

In accordance still further with the eighth aspect of the present inven- 
tion, the presence client program is characterized in that a presence set com- 

20 prises one or more attributes belonging to a single publisher role in association 
with a single presence group. A user interacting with the system as a publisher 
is able to use the presence client program or more than one presence client 
program in more than one publisher role. Each attribute may part of an item in- 
cluding an attribute name element and an attribute value. 

25 Still further in accord with the eighth aspect of the present invention, 

the presence client program is characterized in that the physical device is a mo- 
bile physical device. 

According to a ninth aspect of the present invention, a physical device 
having a computer program embodied in a computer-readable medium stored 

30 therein, is characterized in that the program is a presence client program 
according to the eighth aspect of the present invention. 

According to a tenth aspect of the present invention, a data structure 
embodied in a computer-readable medium for storage in a physical device, is 
characterized in that the data structure is a presence database for storing valid 

35 values of presence sets of attributes of one or more publishers for access by 
subscribers according to presence groups associated with the presence sets. 
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In further accord with the tenth aspect of the present invention, a data 
structure is characterized in that each attribute is part of an item including an at 
tribute name element and an attribute value. The name element may include a 
qualifier having information related to attribute usage. The name element may 
5 include an authority string indicative of an authority responsible for keeping the 
name element and attribute value unique. 

In still further accord with the tenth aspect of the present invention, a 
presence set comprises one or more attributes belonging to a single publisher 
role in association with a single presence group. 
10 Further still in accord with the tenth aspect of the present invention, 

the data structure is characterized in that a user interacting with the physical de- 
vice as a publisher is able to use the data structure to publish more than one 
publisher role, each role having distinct presence sets in association with distinct 
presence groups. 

15 In accordance still further with the tenth aspect of the present inven- 

tion, a data structure is characterized in that the physical device is a mobile de- 
vice. 

According to an eleventh aspect of the present invention, a physical 
device having a data structure embodied in a computer-readable medium stored 

20 therein, is characterized in that the data structure is a presence database ac- 
cording to the tenth aspect of the present invention. 

Advantages of the invention are that it is possible to adjust predeter- 
mined presence attributes by adding a qualifier. The qualifier may be used to 
add a new attribute (as an attribute with a qualifier can be uniquely identified, i.e. 

25 functionally separated from an attribute with same attribute name but without 
qualifier). Thus e.g. users or application developers can easily determine new 
presence attributes best fitting their needs or describing their current actual 
status without being limited to the predetermined types. The use of the qualifier 
brings another advantage as it enables the sender of presence information (the 

30 owner) to further specify how the presence information is to be used in the re- 
ceiving client device. 

In one embodiment of the invention the application to which the at- 
tribute should be addressed is specified in the qualifier. The received attribute is 
addressed to the application indicated in the qualifier. The further advantage of 
35 this embodiment is that the sending client device may define the used applica- 
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tion and thereby use qualifier to direct certain presence information to a certain 
application. 

Another advantage of the invention is the showing of how to assem- 
ble presence items with names, attributes and values in a single presence set 
5 within a role having an associated authorization group of members that have the 
right to subscribe to the whole or part of the presence set of the same role. 

Brief Description of the Drawings 

In the following, the invention will be described in further detail by 
means of preferred embodiments and with reference to the accompanying draw- 
10 ings, in which 

Figure 1 is a block diagram illustrating a mobile IMPS system; 

Figure 2 is a signalling diagram illustrating the transmission of pres- 
ence attributes; and 

Figure 3 is a signalling diagram illustrating the usage of a qualifier. 
f5 Figure 4 shows one embodiment of a mobile messaging system 

comprising at least one client device and a server, according to the present in- 
vention. 

Figure 5 shows another embodiment of a mobile messaging system 
comprising at least one client device and a server, according to the present in- 
20 vention. 

Figure 6 shows a presence framework, according to the present in- 
vention. 

Figure 7 shows a presence database, according to the present inven- 
tion. 

25 Figure 8 shows flow diagrams of unsubscribed presence, according 

to the present invention. 

Figure 9 shows subscribed delivery of presence information, accord- 
ing to the present invention. 

Figure 10 shows management of user groups and presence sets, ac- 
30 cording to the present invention. 

Best Mode for Carrying out the invention 

Figure 1 illustrates a mobile IMPS system. A number of mobile clients 
(MC) can be connected via a mobile network MNW and possibly one or more in- 
35 termediary networks ONW to an IMPS server S. Typically the Internet is used as 
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the intermediary network, also non-mobile clients C may be served by the IMPS 
system. The IMPS server S can be, as regards presence services, functionally 
divided into server elements: A publisher server PS that is the home service 
element for a publishing client owning the presence information and a sub- 
5 scriber server SS that is the home for a subscribing or requesting client. Thus 
the client MC is served by both servers; the MC updates its presence informa- 
tion to the PS and acts as a publishing client and on the other hand requests 
and receives presence information relating to other clients as presence attrib- 
utes from the subscriber server SS. The server PS maintains presence data and 
10 manages its distribution based on the users' publishing preferences relating to 
presence information. The functions of SS and PS may be carried out on one 
physical server device or distributed to a plurality of server devices. 

It should be noted that the present description focuses on presence 
related service capabilities. Other important mobile IMPS service capabilities are 
15 messaging capabilities, user group management capabilities, content manage- 
ment capabilities, subscriber management capabilities, and client capabilities. 
Mobile IMPS services are created by using these service capabilities. For in- 
stance, a client MC may belong to several user groups and the server S man- 
ages the group memberships, handles instant messaging and delivers presence 
20 information between the members of the group. One important role of the server 
is also to control information flow; the server may have filters on the basis of 
user preferences defining e.g. what presence or other information can be deliv- 
ered to members of a group 'Friends', to members of a group 'Work colleagues' 
or publicly to any client. 

25 Various transport layer protocols may be used and the IP protocol is 

typically used to provide a network layer service. Different lower layer transmis- 
sion protocols may be used. The mobile network MNW can be any wireless 
network, such as a cellular network supporting the GSM service, a network sup- 
porting also the GPRS service (General Packet Radio Service), a third- 

30 generation mobile communication network, such as a UMTS network (Universal 
Mobile Telecommunications System), a wireless local area network WLAN or a 
private network. Also short range infrared or radio connections, such as a Blue- 
tooth™ communication, may be used as a part of the communications path be- 
tween the MC and the server S. The mobile client device MC may be e.g. a mo- 

35 bile station, a PDA device or a laptop computer comprising or being connected 
to a wireless modem. The mobile IMPS messages may be transferred using a 
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circuit-switched data call, a packet-switched data transmission context, messag- 
ing services such as SMS or MMS (Multimedia Messaging Service), for- 
instance. Figure 2 illustrates the usage of presence attributes. As the mobile cli- 
ent MC has determined 201 one or more presence attributes to be published, it 
5 updates 202 presence attributes to the publisher server PS, i.e. publishes one or 
more presence attributes. The determination 201 of presence attributes can be 
done when the client is establishing a logical mobile IMPS session with the mo- 
bile IMPS server or automatically or by a user initiative when some presence in- 
formation has changed. For instance, phase 201 may be initiated automatically 

10 at a pre-determined time, data, or by a change of user profile at the mobile client 
MC. When a client MC (A) accesses mobile IMPS services of a server SS, it 
may request 203 presence information on another client (B). The subscriber 
server SS requests 204 this information from the publisher server PS (of client 
A). The PS sends 205 one or more presence attributes to SS, if this is allowed 

15 by the publication preferences (of client B). It is possible that the publication 
preferences set by client B prevent some part of the requested information from 
being sent (to client A or in general). The SS may also automatically request 204 
presence information on the basis of the user preferences (of A) when the client 
establishes a logical connection with the service of the SS. The SS forwards 206 

20 the presence attributes to the receiving client MC (A). 

The subscriber server SS (and the publication server PS) typically 
send the client-originated presence attributes towards the client unmodified. 
However, there may exist a content adaptation mechanism implemented in the 
server PS. Content adaptation addresses the issue of modifying a presence at- 

25 tribute in such a way that it matches the client capabilities of the receiving client. 
In addition to the transmission of presence information as a response to a re- 
quest from a client, it is also possible to push presence information to available 
clients MC (that are logically connected to the service) according to the publica- 
tion preferences. The push-type presence notification can be triggered by three 

30 mechanisms: when the publisher server receives an update from the publisher 
client, when the publisher server detects a change in the attribute value or by 
implementation-specific internal triggers updating the value. 

The client MC is thus configured to update one or more presence at- 
tributes to the PS, to receive and handle 207 the presence attributes received 

35 from the SS and to present presence information obtained from at least one 
presence attribute to the user. The MC preferably stores presence information 
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(presence attribute values) until new presence attribute values are received in 
an update message used to cany presence attributes (or the client finishes the 
mobile IMPS session). Further, as will be illustrated in more detail later, the cli- 
ent device may automatically utilize received presence information to adjust its 
5 function accordingly. In addition to the signallings shown in Figure 2, an authori- 
zation may be requested from the publisher of the presence information before 
sending presence attributes to a requesting client. Figure 2 does not show any 
status messages by which the server may respond, e.g. after the message 202. 

A client originated presence attribute is one which has its value field 
10 filled in by the publishing client. A server originated presence attribute is one 
which has its value field filled in by the publisher server. A presence attribute is 
client-server originated when one part of the value field is filled in by the client 
and the rest by the publisher server. According to a preferred embodiment of the 
invention, users or organizations may define new presence attributes besides 
15 the predetermined set of attributes. The presence attributes can be divided into 
the following classes: 

Client Status: Presence attributes describing the availability of the cli- 
ent device for communication; network reachability, GPRS attached, 
on/off status, operator, for instance. Thus the attributes in mobile 
20 IMPS service are very different than in IMPS used for non-mobile cli- 

ent devices. 

User Status: Presence attributes describing the availability of the user 
for communication; ready, meeting, busy, away, on the phone, chat- 
ting, do not disturb, for instance. 

25 - Local Information: Presence attributes describing the local environ- 
ment at the user; local time, noisy/silent environment, in-door, out- 
door, location of the user, in terms of, for instance, geographical loca- 
tion, visited PLMN, city/street, premises, for instance. For instance, 
the exact location of the mobile client may be obtained for the local 

30 information attribute directly and the availability status (in a meeting, 

in a summer cottage, etc) may be readily available via user profile 
settings of the mobile client MC. 

Personal Status: Various personal attributes describing personal user 
status; mood, personal interests and intentions, for instance. 
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Client Capabilities: Presence attributes describing the capabilities of 
the client device to support different means of communication, differ- 
ent media types and different features. 

User Attributes: Presence attributes allowing the client device or the 
5 user to define their own textual presence values and references to ex- 

ternal values. 

Extended Presence Information: Vendor specific or service provider 
dynamically defined non-standard presence attributes which however 
need to be passed through standard presence servers. 
10 Thus there may be different presence attributes for mobile client de- 

vices and actual users. For instance, the user may be defined as not being 
available for receiving messages but the user's client device is defined as being 
on-line. The user may also be defined to be able to receive messages and not 
being online if SMS is used as a bearer. 

15 

GENERAL STRUCTURE AND IDENTIFICATION 
OF PRESENCE ATTRIBUTES 

Table 1 describes the general structure of presence attributes, A 
20 presence attribute generally comprises an identifier part and a plurality of value 
fields. The Req field determines whether the element is mandatory M, optional 
O or conditional C. Attribute information is in XML format (Extensible Markup 
Language). 



Information 
Element 


Req 


Type 


Description 


NameSpec 


M 


XML 


Attribute identity information 


Value 


M 


XML 


Value for the attribute 



25 Table 1. Presence Attribute Structure 



The sub-elements of the Namespec element are described in Table 



30 
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NameSpec 


Req 


Type 


DescriDtion 


Name 


M 


String 


Name of the attribute 


Qualifier 


O 


String 


Information related to the scope of at- 
tribute usage 


Authority 


C 


String 


The authority responsible for the fact 
that attribute NameSpec and value 
field names are unique 



Table 2. The NameSpec element 



The name of the attribute is a string given by the information element 
5 'Name'. The Name information element is defined for all presence attributes in 
the format defined in Table 3. 



Informa- 
tion 

element 


Name 


Data 
type 


String 


Format 


Free text format 


Descrip- 
tion 


Name of a presence attribute 



Table 3. The Name element 

10 
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The format of the Qualifier element is illustrated in Table 4. 



Informa- 
tion 

element 


Qualifier 


Data 
type 


String 


Format 


Free text format 


Descrip- 
tion 


Modifies the scope of attribute usage 



Table 4. The Qualifier element 



5 

The Qualifier element is used to specify the scope of the attribute us- 
age. The qualifier can be used especially for two purposes: to add a new attrib- 
ute or to enable the sender of presence information (the publisher) to specify 
how the presence information is to be used in the receiving client device. Thus 

10 the qualifier string may be used as a parameter for one or more applications in 
the receiving client device. 

For instance, if the publisher wants to limit the knowledge of his exact 
location (e.g. the street address) to only some of the users (call it group A) and 
give a more approximate location (e.g. only a city name) to others (call it group 

15 B), he may publish a location attribute with the city name to group B. For group 
A he attaches a Qualifier (say 'My best friends') to the location attribute. This ef- 
fectively creates a new attribute with Qualifier 'My best friends'. He then includes 
the street address in this new attribute and publishes it to group A. As these at- 
tributes are different, the server PS is able to keep their values separate. Also if 

20 a person belongs to both groups A and B, the client device of this person can be 
configured to distinguish between these two attributes. The client device may be 
configured to present (and possibly utilize) the attribute according to the group 
which the user has activated. The possible Qualifier values may be preassigned 
by the client and the service provider or they may be assigned dynamically by 

25 the user (publisher). A service provider may also limit the number of dynamically 
assigned Qualifier values. 
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The authority element determines the body who is responsible for 
keeping the attribute and its contents unique. This relates to the attribute extent 
sion mechanism. 



Informa- 
tion ele- 
ment 


Authority 


Data type 


String 


Format 


URL 


Descrip- 
tion 


Identifies the body responsible for the uniqueness of the 
attribute 



5 Table 5. The Authority element 

When predetermined presence attributes are used unmodified, the 
Authority string can be omitted. Use of a Qualifier string is not a modification to 
the attribute that requires the use of the Authority element. It must be used when 

10 introducing a new attribute (a new Name) or when adding a new value field to an 
already specified attribute. In both of these cases the attribute is considered to 
be a new one and the Authority is responsible for maintaining this new attribute. 

Generally a Value field name must be unique within an attribute. 
Thus, the introduction of a new value field to an existing attribute must be han- 

15 died by the rules set by the body who has defined the attribute. Adding a new 
value field transforms the old attribute into a new one. This must be signalled by 
the presence of the Authority field in order to allow both the new and the old at- 
tribute to co-exist. It is also possible that a stakeholder releases an attribute for 
public maintenance. This kind of attribute is registered by a proper authority, 

20 such as IANA (Internet Assigned Numbers Authority), and also signaled in the 
Authority field. In this case any stakeholder may register additional value fields 
for the attribute without having to change the Authority field. The server (PS, SS) 
does not remove a value field from an attribute even though it would not under- 
stand the semantics of the value field. The client MC ignores all the value fields 

25 in the attribute that it does not understand. 

An attribute is identified and made unique by the element NameSpec. 
Figure 3 shows an example of the use of the NameSpec element and the quali- 
fier. A qualifier is determined 301 for an attribute in client device MC1. It is pos- 
sible that the user determines the qualifier or that the client device MC deter- 
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mines it. The qualifier may be defined in order to specify the desired the user 
group, determine how to present the presence information in a receiving client 
device (MC2), or otherwise to specify how the receiving client device MC2 
should use the attribute. It is possible to utilize the user profiles of the mobile cli- 

5 ent MC when determining the qualifier. For instance, the MC1 composes pres- 
ence attribute on the basis of the current profile (e.g. on a meeting), calendar 
entries (meeting ends at 12.00) and the local time. By using the qualifier, the 
presence attribute can be easily modified to include a lot of useful information 
for the receiving client MC2. The attribute is sent 302 to the server PS. 

10 PS compares 303 the NameSpec element of the received attribute to 

already stored attributes. The PS first compares the Authority strings with each 
other. An attribute not containing an Authority string is different from any attrib- 
ute that has an Authority string. Next the attribute names are compared. Finally 
the Qualifier strings are compared. An attribute that does not contain a Qualifier 

15 string is different from any attribute that has a Qualifier string. Two attributes are 
the same only when all of these three comparisons give the same result. Thus it 
is possible to functionally separate the received attribute with the qualifier from 
attributes with same attribute name but with a different qualifier. 

The publication server PS does this kind of comparison to determine 

20 whether the value fields of the received attribute shall replace some already ex- 
isting presence information or whether the attribute is a new one to be added to 
the presence information storage of the MC2. On the basis of the comparison, 
the PS stores 303 the information in the received attribute. The PS replaces 
previous presence information of an already stored attribute with the presence 

25 information of said received attribute if all identifiers of said received attribute 
are the same as in already stored attribute. Otherwise the PS adds the presence 
information of said received attribute without replacing any previous information. 
PS sends 304 the attribute to at least one client device MC2 (either automati- 
cally pushes it or as a response to a request from the MC2). According to an 

30 embodiment, the qualifier determines a group to which the attribute is directed. 
Further, the qualifier may be used to present presence information in different 
ways for private contacts and public contacts in a phone book, for instance. 
Thus the PS may determine the receiving client devices on the basis of the 
qualifier. Service capabilities for a dynamic phone book service will be de- 

35 scribed later, after first describing the client status attributes, user status attrib- 
utes and personal status attributes more fully below. 
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10 



Also the receiving client MC2 decides, after a similar comparison 305 
as in PS, whether and how to store the information of the received presence at- 
tribute. This kind of ternary identification of presence attributes enables very 
flexible usage, management and creation of presence attributes. 

There are many ways in which the qualifier may be used to specify 
the usage of the attribute in the client device MC2. Typically the client device 
MC is capable of supporting a plurality of applications. According to a first em- 
bodiment, the client device MC1 adds a qualifier specifying an application to be 
used. Application refers generally to any application entity which can be identi- 
fied e.g. by a port number. The application may be the same as used to process 
the presence information of the attribute in the client device MC1 or another ap- 
plication. The receiving client device MC2 addresses 305 the received attribute 
to the application indicated by the qualifier. For instance, by using the qualifier, 
the same presence information may be sent to a phone book application and a 
15 game application. These applications may use the presence information differ- 
ently and thus it is possible also to tailor attributes exactly for application needs. 

According to a second embodiment, the client device MC1 adds a 
qualifier specifying the presentation of the attribute. The receiving client device 
MC2 presents 305 the received attribute on the basis of the qualifier. The quali- 
20 fier may determine e.g. whether the information is shown to the user at all or not 
or which parts of the information are shown. The qualifier may also determine 
various user interface settings such as colors, fonts etc. Thus the Ul of the MC2 
is configured 305 on the basis of the settings in the qualifier. 



25 



35 



CLIENT STATUS ATTRIBUTES 



According to a preferred embodiment, the mobile clients MC utilize a 
presence attribute which describes the current transmission capabilities of a 
30 mobile client MC. A structure for this kind of attribute is illustrated in Table 6. 
This attribute, referred to as a Modem attribute, gives presence information on 
those user terminal parts or functions that are dealing with mobile bearers. 
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Infor- 
mation 
Ele- 
ment 


Req 


Type 


Value 


Description 


Name 
Spec. 
Name 


M 


String 


Modem 


Name of the attribute 


Value 


M 


XML 


See Table 7 
below 


Value for the attribute. 
Type Is a structure 



Table 6. Modem Attribute Structure 



Modem.Value 


Req 


Sin- 

gle/MuIti 
pie 


Description 


Status 


M 


S 


Name of the Value field 


CommAddr 


O 


S 


Name of the Value field 


CS Status 


O 


S 


Name of the Value field 


PS Status 


O 


S 


Name of the Value field ! 


Roaming- 
Status 


O 


S 


Name of the Value field 


CS CallStatus 


O 


M 


Name of the Value field 


PDP_ContexS 
tatus 


O 


M 


Name of the Value field 



Table 7. Value fields of Modem attribute 

5 

The Status value field as illustrated in Table 8 indicates the status of 
the mobile modem. 



10 
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Informa- 
tion ele- 
ment 


Status 


Data type 


Enumerated Strinq 


Format 


Following values: 

ON - The modem part of the terminal is powered on 
ui-i- - i ne modem part of the terminal is powered off or 
out of coverage 

DIS - The value fields (If any) given by this attribute are 
invalid. All the value fields obtained from earlier updates 
are invalid 


Descrip- 
tion 


Status field of the modem attribute 


Range 


ON | OFF | DIS 



7ab/e 8. Status value field of Modem 



The Status value field indicates whether the modem is turned on or 
5 off. According to a preferred embodiment, a presence attribute includes a DIS 
indication preferably in the mandatory Status value field of the attribute. When 
DIS is set in an attribute, all values given in the attribute are invalid. The receiv- 
ing mobile client MC is thus able to ignore the value fields of the attribute. Also 
previous values of the presence attribute are removed (and nulled). Thus it is 
10 practical to send an attribute with DIS indication but no other value fields. This 
kind of attribute requires very little space and thus critical bandwidth over the ra- 
dio interface can be saved. This is very useful especially with attributes describ- 
ing user attributes. 

Referring again to Table 7, the CommAddr value field of the Modem 
15 attribute includes the communication address of the modem (MC). It contains 
two parts: the communication means and the contact address. The means part 
carries information about the supported communication methods, especially 
whether the modem supports packet-switched (PS) data, circuit-switched (CS) 
data or voice, SMS or MMS. The Contact part includes the address, e.g. an 
20 MSISDN number. 

The CS_Status value field indicates the circuit switched status of the 
modem (registered or not registered). The PS_Status value field indicates the 
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packet switched status of the modem (attached or not attached). The Roam- 
ingStatus value field indicates the home PLMN (Public Land Mobile Network) 
and possibly the PLMN in which the modem is currently roaming. The 
CS_CallStatus value field gives the in-call status of a CS bearer (data or voice; 
5 active or not active). The modem attribute may have a list of these in-call sta- 
tuses in case if multicall capability is supported by the modem. The 
PDP_Context Status value field includes information about the PDP (Packet 
Data Protocol) context, such as QoS (Quality of Service) information. 

In addition to above examples, the modem value field may be used to 

10 carry other information related to transmission capabilities of the mobile client. In 
a first example a maximum bit rate of the mobile client is delivered in the Mode 
attribute. The receiving client device can then configure its transmission rate so 
that the maximum bit rate is not exceeded. In a second example the client de- 
vice determines that only the packet-switched transmission mode is to be used 

15 when sending data files to the client device. A third example is that a roaming 
device orders that only certain type of communication is enabled (e.g. only voice 
calls are allowed and data files shall not be sent). 

USER STATUS ATTRIBUTES 
20 According to one preferred embodiment, an attribute is defined for 

the willingness of the user to engage in an activity. The activity is specified by 
the value fields belonging to this Availability attribute. Table 9 illustrates the 
structure for the Availability attribute. 



Infor- 
mation 
Ele- 
ment 


Req 


Type 


Value 


Description 


Name 
Spec. 
Name 


M 


String 


Availability 


Name of the attribute 


Value 


M 


XML 


See Table 10 
below 


Value for the attribute. 



25 Table 9. Availability Attribute Structure 

Table 10 describes the value fields of the Availability attribute. 
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Availability- 

Extension- 

Value 


Req 


Single/ 
Multiple 


Description 


Status 


M 


S 


Value field name 


CommAvail 


0 


S 


Value field name 


PhoneAvail 


O 


S 


Value field name 


SMSAvail 


O 


S 


Value field name 


MMSAvail 


O 


s 


Value field name 


IMAvail 


O 


s 


Value field name 


EmailAvail 


O 


s 


Value field name 


Image 


O 


M 


Value field name 


Text 


O 


M 


Value field name 



Table 10. Availability attribute values 



5 The status value field as illustrated in Table 1 1 indicates the status of 

availability information. 



Informa- 
tion ele- 
ment 


Status 


Data type 


An enumerated String 


Format 


One of the following values: 

ENA - The value fields included in this attribute contain 
up-to-date information. The value fields updated earlier 
and not included in this attribute are still up-to-date 
DIS - The value fields (if any) included in this attribute 
contain invalid information. The value fields updated 
earlier are invalid. 


Descrip- 
tion 


Defines the publishing status of availability attribute 


Range 


ENA | DIS 



Table 11. Status field 

10 
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The Status value field indicates whether the publishing of availability 
information is enabled or not. The DIS indication may be used as already de- 
scribed to invalidate the values of the Availability attribute. For instance, the 
server PS may send an availability attribute with DIS indication after the mobile 
5 client MC has closed the mobile IMPS session. This kind of message may also 
be sent when a connection to client is suddenly lost. Thus the receiving mobile 
client can remove all availability information relating to the user and the client 
device that are no longer present in the mobile IMPS system. 

10 The CommAvail value field in Table 10 indicates whether the user is 

willing to engage into any form of remote communication. The PhoneAvail value 
field indicates whether the user is willing to engage in a telephone call. The 
SMSAvail value field indicates whether the user is willing to engage in an SMS 
exchange. The MMSAvail value field indicates whether the user is willing to en- 

15 gage in an MMS (Multimedia Messaging Service) exchange. IMAvail value field 
indicates whether the user is willing to engage in an IM (Instant Messaging) ex- 
change. The EmailAvail value field indicates whether the user is willing to en- 
gage in an EMAIL exchange. 

20 The structure for Image value field is illustrated in Table 12. 



Image 


Req 


Description 


Containedl- 
mage 


C 


An image included in the attribute in transfer 
encoded form 


Referred I- 
mage 


C 


A URL to the image 


Value Field 


M 


The name of any Value Field in this attribute 
except Status, Image or Text 



Table 12. Image 



This value field associates an image with any of the value fields in the 
25 Availability attribute except in the Status, Text or Image field. The Containedl- 
mage value field includes the image, the size or the format of the image may 
however be restricted. The Referredlmage value field includes a URL to re- 
source having the associated image. The ValueField value field defines the 
value field the image is associated with. For instance, the publisher may associ- 
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ate an image with the value field PhoneAvail which currently has value 'DISC 
(meaning that the user is limitedly available for telephony, for instance) in order 
to convey pictorial semantic information about the meaning of DISC. The Image 
value field may have multiple instances in this attribute. Whenever this value 
5 field is included in the attribute, its target value field must also be included in the 
same attribute. The association is valid only as long as the target value field is 
valid. When the target value field is updated or invalidated, any old association 
with this attribute must be discarded by the receiving client. 

10 The structure for Text value field is illustrated in Table 13. 



Text 


Req 


Description 


Contained- 
Text 


M 


A text string 


ValueField 


M 


The name of any Value Field in this attrib- 
ute except Status, Image or Text 



Table 13. Text 



Text value field associates a text string with any of the value fields in the Avail- 
ability attribute except in the Status, Image or Text field. The Text value field in- 

15 eludes the text string in ContainedText and the name of the associated value 
field in ValueField. The size of the text may be limited in the ContainedText ele- 
ment. For example, the publisher may associate a text with value field Pho- 
neAvail which currently has value 'NAVL' (e.g. 'in meeting until 14:00') in order 
to convey additional semantic information about the meaning of NAVL. The Text 

20 value field may have multiple instances in this attribute, i.e. the same text may 
be associated with a multiple value fields. Whenever this value field is included 
in the attribute, its target value field must also be included in the same attribute. 
The association is valid only as long as the target value field is valid. When the 
target value field is updated or invalidated any old associations with this value 

25 field must be discarded by the receiving client. Images and text may also be 
automatically added to a presence attribute. 



30 
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PERSONAL STATUS ATTRIBUTES 

PersonalStatus attribute indicates the personal status of the pub- 
lisher. The options and details are specified by the value fields belonging to this 
5 attribute. Table 14 illustrates attribute structure for the PersonalStatus. 



Informa- 
tion Ele- 
ment 


Req 


Type 


Value 


Description 


Name- 
Spec. Na 
me 


M 


String 


Personal- 
Status 


Name of the attribute 


Value 


M 


XML 


See Table 15 
below 


Value for the attribute 



Table 14. PersonalStatus attribute structure 



10 Table 15 illustrates the value fields of the PersonalStatus attribute; 



Personal- 
Status.Value 


Req 


Sin- 

gle/MuIti 
pie 


Description 


Status 


M 


S 


Name of the value field 


Text 


O 


S 


Name of the value field 


Mood 


O 


S 


Name of the value field 


Time 


O 


S 


Name of the value field 


Image 


O 


M 


Name of the value field 



Table 15. PersonalStatus attribute values 



The status value field as illustrated in Table 16 indicates the status of 
15 PersonalStatus information. 
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Informa- 
tion ele- 
ment 


Status 


Data type 


An enumerated String 


Format 


One of the following values: 

ENA - The value fields included in this attribute contain 
up-to-date information. The value fields updated earlier 
and not included in this attribute are still up-to-date 
DIS - The value fields (If any) included in this attribute 
contain invalid information. The value fields updated ear- 
lier are invalid. 


Descrip- 
tion 


Defines the publishing status of location attribute 


Range 


ENA | DIS 



Table 16. Status of PersonalStatus attribute 



This field indicates whether the publishing of this information is en- 
5 abled or not. The DIS indication may also be used with the PersonalStatus at- 
tribute. 

The Text value field indicates the status of the publisher in a free text 
form. The Mood value field indicates the mood of the publisher. The Time value 
field gives the local time of the publisher. 

1 o According to a preferred embodiment, an image may also be utilized 

in the PersonalStatus attribute. As already illustrated in Table 12 the Image 
value field associates an image with any of the value fields in this attribute ex- 
cept in the Status or Image field. For instance, the publisher may associate an 
image with value field Mood which currently hasvalue 'IN_LOVE' in order to 

15 convey pictorial semantic info about the meaning of IN_LOVE. The Image value 
field may be used in a similar way as already illustrated with attribute Availability. 

The present invention can be implemented in the existing client de- 
vices and servers. They all have processors and memory with which the inven- 
tive functionality described above may be implemented. A computer program 

20 may be loaded from an internal or external memory to the processor of the 
server or the client device, causing, when executed in the processor, the means 
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to implement the inventive functionality. Also hardware implementation or a 
combination of software and hardware implementation may be used. 

Fig. 4 shows a client device 402 in communication with a server 404, 
according to the present invention. The client device may be similar to one or 
5 more of the mobile clients or the non-mobile client of Fig. 1 or any of the other 
mobile clients shown in Figs. 2 and 3. Likewise, the server 404 may be similar 
to the server shown in Fig. 1 or any of the other servers shown in Figs. 2 and 3. 
The client device 402 includes means 406 for transmitting or requesting pres- 
ence information as presence attributes to the server on a signal line 408. 

10 Transmitting presence information would correspond for instance to the step 
302 of Fig. 3 in which presence attributes are sent from MC1 to PS or the step 
202 of Fig. 2 in which presence attribute(s) are updated by the MC and sent to 
the PS. Requesting presence information on the line 408 would be comparable 
to the request step 203 of Fig. 2 wherein the MC requests a presence attribute 

15 from the SS. The transmission on the line 408 from the client device 402 to the 
server 404 could be similar to the transmission path shown in Fig. 1 from a mo- 
bile client (MC) through a mobile network (MNW) via an intermediary network 
ONW to the IMPS server(s). Or, it could be similar to the path from the non- 
mobile client C through the intermediary network ONW to the server S. Of 

20 course other possible paths are contemplated as well and the invention does not 
depend on the path of the physical media or combination of physical media 
used. The client device 402 also includes means 410 for receiving presence at- 
tributes from the server 404 on a signal line 412. Such presence information is 
categorized by a plurality of presence attribute types identified by attribute 

25 name. 

The server 404 includes means 414 for receiving/transmitting attrib- 
utes and for maintaining presence information based on the received presence 
attributes. 

According to the invention, the client device 402 additionally includes 
30 means 416 for adding a qualifier to a presence attribute wherein the qualifier 
comprises one or more parameters specifying the use of the attribute. The 
added qualifier is provided on a signal line 418 for transmission by the means 
406 on the line 408 to the server 404. This may be done via a means 420 for 
determining presence attributes in accordance with instructions received on a 
35 line 422 from an application 424. The application can also utilize the means 420 
for requesting presence attributes. In either event, a signal may be provided on 
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a line 426 from the means 420 to the means 406 for transmitting or requesting 
presence attributes on the line 408. In case the means 416 has added a quali- 
fier, for instance in updating a presence attribute as per step 202 of Fig. 2, the 
signal on the line 408 will include a presence attribute with a qualifier having one 
5 or more parameters specifying use of the attribute. 

For handling presence attributes incoming on the line 412 from the 
server 404, the client device 402 will also include means 428 for processing a 
received presence attribute on the line 412 from the server 404 according to 
qualifier parameters in the received attribute. The received presence attribute 
10 on the line 412 may be received by the means 410 and provided on a line 430 to 
the means 428 for processing the received attribute. After processing, the 
means 428 may provide a signal on a line 432 to the application 424 for further 
use by the application. 

The means for adding a qualifier 416 may include means 434 for 
15 specifying in the qualifier presentation settings of the attribute so that the client 
receiving the attribute from the server 404 will be able to present the attribute on 
the basis of the presentation settings. Consequently, a client device such as the 
client device 402 of Fig. 4 will include means 436 for presenting received attrib- 
utes on the basis of such a qualifier specified by another client device and re- 
20 ceived from the server 404 on the line 412. 

Likewise, the means 416 may include a means 438 for specifying in 
the qualifier to be sent to the server 404 an application to which the attribute 
should be addressed in the receiving client. For such a client device 402 receiv- 
ing a qualifier specifying the application to which the attribute should be ad- 
25 dressed, it will have means 440 for interpreting such an attribute received on the 
line 430 for addressing a received attribute to the application indicated by the 
qualifier. 

Turning now to the server 404 in more detail, it may also include 
means 444 for determining on the basis of a qualifier whether to send an attrib- 

30 ute to one or more client devices such as specified by a presence group in a 
presence database in the server. Such a determination may also depend on an 
authorization provided on a line 446 from a means 448 for providing such au- 
thorization. If the qualifier and authorization indicate that the attribute should be 
sent to one or more client devices, then the server 404 will do so, for instance to 

35 the client device 402 as well as similar devices, if appropriate. 
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It may be that a presence attribute intended for a particular client may 
not match that client's capabilities, according to information known to the server. 
Such information may be provided for instance by the means 444 on a line 450 
to a means 452 for modifying the presence attribute to match the clients capa- 
5 bilities. The modified attribute may be provided back to the means 444 on the 
line 450. On the other hand, in cases where presence attributes are provided 
according to a "push" technology, the modified presence attribute may be pro- 
vided on a line 454 to a means 456 which is capable of taking the appropriate 
steps to push the modified presence attribute to the client or to more than one 
10 client, as appropriate. This may be signalled for instance on a line 458 to the 
means 444. 

It should be realized that the functional blocks shown in Fig. 4 may be 
carried out using discrete hardware, specialized integrated circuits, microcontrol- 
lers, software, firmware, etc., as will be apparent to those of skill in the art. 

15 Moreover, the functions attributed to distinct functional blocks in the figure need 
not be separate but can be incorporated in other blocks by free addition or sub- 
traction of functions into or from other functional blocks. Likewise, the coopera- 
tive relationships between the functional blocks may be modified in their order 
and interrelationships while at the same time carrying out the same end results 

20 mentioned above. It should also be realized that the details of the client device 
and server device shown in Fig. 4 can take other forms which are similar to 
those shown, according to the invention. Other aspects of the invention can be 
illustrated in a similar but by no means identical way. 

For instance, Fig. 5 shows a client device 502 communicating with a 

25 server device 504 with means 506 similar to the means 420 of Fig. 4 for trans- 
mitting presence information as presence attributes on a line 508 to a means 
510 for receiving and maintaining presence attributes within the server 504, 
similar to the means 414 within the server 404 of Fig. 4. Likewise, the client de- 
vice 502 may include means 512 for receiving presence attributes indicative of 

30 presence information on a line 514 from the means 510 of the server 504. Simi- 
lar to the means 420 and 416 of the client device 402 of Fig. 4, the client device 
502 of Fig. 5 may include means 516 for composing a presence information at- 
tribute identified by a combination of an authorizes an attribute name and a 
qualifier, the authorizer specifying a body responsible for maintaining the attrib- 

35 ute and the qualifier specifying the use of the attribute. The so-composed at- 
tribute may be provided on a line 518 to the means 506 for transmittal on the 
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line 508 to the server 504, as shown. The server 504 may include means 520 
that is responsive to the so-composed attribute received on a line 522 from the 
means 510 for searching for already stored attributes containing the same com- 
bination of authorization, attribute name and qualifier. If the combination of 
5 identifiers of the received attribute is identical to that of the already stored attrib- 
ute, for instance stored in a storage means 524, the received attribute is used to 
replace the already stored attribute over a signal line 526. In this way, if the at- 
tribute parameters have changed, the updated parameters will be stored in the 
storage means 524. Otherwise, the received attribute is added to the storage 

10 means as a new attribute. This function may be carried out in the means 520 as 
described above, or may be carried out in a completely separate means 528 
which receives the received attribute on a line 530 from the means 520 and in- 
cludes functions for replacing the already stored attributes with the received at- 
tributes if the combination of identifiers are the same and otherwise adding the 

15 received attribute over a connection line 532 between itself and the storage 
means 524. 

The client device 502 will include similar functionalities as just de- 
scribed above as shown for instance by a means 540 which receives incoming 
attributes on a line 542 from the means 512 and searches for already stored at- 

20 tributes containing the same identifiers as the received attribute and means 542 
for replacing the already stored attribute with the received attribute if the combi- 
nation of identifiers of the received attribute is identical to that of the already 
stored attribute. Otherwise, the received attribute is added to a storage means 
544. The means 540 for searching may include the means 542 within or they 

25 may be separate as shown in the figure. In the latter case, a signal line 546 
provides attribute information concerning the received attribute from the means 
540 to the means 542. The storage means 544 may be in bi-directional com- 
munication over line 548 with the means 542 for replacing or adding attributes 
and the line 550 with the means 540 for searching for already stored attributes. 

30 As mentioned above, the service capabilities for a dynamic phone- 

book service embodiment of the present invention will now be described. A dy- 
namic phonebook service can be viewed as a rich call service. It is useful "be- 
fore the call" to enrich cases where B party's presence information is shown to 
the A party. In this case, the B party is one or more of the user phonebook en- 

35 tries. The presence information can be divided into the same categories as 
mentioned above, i.e., (1) client availability, (2) user availability, (3) local condi- 
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tions, (4) personal status, (5) client capabilities, (6) user attributes, and (7) ex- 
tended presence service: 

Conceptually, the Presence System consists of Presence Clients 602, 
5 604, 606, Presence Users 608, 610, 612, Presence User Roles 614, 616, 618, 
620, 622, 624, Presence Proxies 626 and Presence Servers 628, 630, as shown 
in Fig. 6. A Presence Client is the software or program which enables for the 
user an interaction with the Presence System. The User is a person who inter- 
acts with the Presence System using the Presence Client. A physical device 

10 632, 634, e.g., mobile handset or PC, may have one 606, or in special cases, 
multiple presence client instances 602, 604. A presence client is owned by a 
single user. A user may own more than one client but then these clients are 
typically in different devices. 

Users 608, 610, 612 are conceptually classified in Publishers and 

15 Subscribers/A publisher is the originator of presence information. A subscriber 
is the receiver of presence information. A User may be both publisher of own 
presence information and subscriber of some other publisher's presence infor- 
mation at the same time. A user may have one or more Roles. A publisher role 
is associated with a set of presence values called Presence Set. The presence 

20 values of two different presence sets of the same user are independent of each 
other and are associated with different roles. A subscriber role is the logical re- 
ceiver of presence information of identical publisher role i.e. of the same pres- 
ence set. 

A Presence Proxy 626 is an optional network element that improves 
25 the scalability of the Presence Service. A proxy temporarily stores presence val- 
ues of different presence sets traveling uplink from the publisher to the server or 
downlink from the server to a subscriber. When a client comes on-line the proxy 
may update the client with current presence information. Also when a publisher 
sends a new presence value to the server the proxy may update all the sub- 
30 scriber clients that are registered with the proxy. A proxy can cache the pres- 
ence values only temporarily. Even when the presence info is coming from the 
publisher the proxy cannot assume that all the updates of this presence info is 
taking place via the same proxy. If the proxy is not aware of the subscriber 
group associated with a presence set then the proxy may ask for this informa- 
35 tion from the server. 
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A presence Server 628, 630 is a network element that maintains valid 
presence values and information on groups that are associated with each pres- 
ence set. The server communicates with presence clients either directly or 
through a proxy. The server informs the proxy about the validity period of pres- 
5 ence values cached by the proxy. When the validity period expires the proxy 
must either discard the values or refresh them from the server. The server as- 
signs the validity periods presence item by item basis by monitoring how fre- 
quently the presence values change. The validity period is dynamic i.e. it may 
change during the lifetime of the presence item. 

10 A presence server exchanges presence information also with other 

presence servers, as shown in Fig. 6. For instance, if the publisher and sub- 
scriber belong admistratively to different presence servers then the presence 
info must go through both servers. In case the servers are incompatible there 
needs to be a gateway function on one or both servers. 

15 Figure 7 shows the structure of a presence database 702, according 

to the invention. A single presence item 704 has three properties: name 708, at- 
tributes 710 and value 712. A presence set 714 consists of a single or more 
presence items. The presence set 714 belongs to a single role 716 of the user. 
There cannot be more than one presence set for a single role. In addition there 

20 is a single authorisation group 718 that belongs to a single role 716. The au- 
thorisation group consists of members that have the right to subscribe the the 
whole or a part of the presence set of the same role. 

The items 704, 720, 722 in a presence set are unique i.e they can 
be distinguished from each other. The items are primarily distinguished from 

25 each other by their name. In case the presence set contains two or more items 
with the same name then there must be an attribute in each item that carries the 
id's of these items. The members 724, 726, 728 of a group 718 are unique. 
Different presence sets in different roles 716, 730, 732 of the same publisher 
734 may contain items with the same name or id. Different groups may likewise 

30 contain the same members. 

A role 716 may be identified by a Role ID, Group ID or Presence Set 
ID. For instance, the Group ID may be assigned by the service provider and is 
unique within the service providers domain. Therefore, the following ID'S would 
be needed to address individual elements in the presence database: 

35 GroupID; ItemName 
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In case the presence set contains more than one Item with the same 
name the ItemName must have the ItemID attribute assigned. 

Note that ID's such as UserlD, DevicelD and ClientID are not needed. 

5 A. EXEMPLARY PRESENCE PROTOCOL 

A. 1 .0 Unsubscribed Presence (Fig. 8) 

The presence information of a user can be obtained separately from 
messaging services by issuing a query to the presence server, as indicated for 
10 instance in the message flows presented in steps 203, 204, 205, 206 of Fig. 2, 
or by subscribing and receiving presence items as in Fig. 9, or by getting pres- 
ence items as shown in Fig. 8. 

The user of a presence service may, at any suitable time, update his 
presence information in the presence server by sending update presence mes- 
15 sage as shown in Fig. 8. As mentioned, a user may issue a get presence mes- 
sage to request the presence information of some other user as also shown in 
Fig. 8. The presence information is delivered back to the requesting user. 

The publisher may update his presence information only partially. 
Similarly, the user may request only partial presence information. 
20 If the user does not have authorisation for a requested presence in- 

formation an empty content is sent to the user. 

The authorisation of presence information for a given user is done by 
including the user into the group corresponding to the presence set. This is de- 
scribed below in the part labeled "Management of presence database'. 

25 

A.1 .1 UpdatePresence 

Direction: Presence Client -> Presence Server 
Content Model: (Transaction! D, GroupID, Presence) 
Attributes: None 

30 Usage: This primitive updates the values of one or more presence 

items on the presence server. The presence items to be updated are carried in 
the information element Presence. If there are items in the Presence that do not 
exist in the server for the given GroupID then the server allocates storage for 
these new items and copies the contents from this message. Otherwise the 

35 server replaces the old value with the new value. 
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No UserlD or PublisherlD is needed in the content. The association 
between the publisher and the XML-document containing the UpdatePresence 
primitive is made in the authentication protocol. 

5 A. 1 .2 Transaction I D 

Content Model: (#PCDATA) 
Attributes: None 

Usage: This is a unique idenfier that associates the request from cli- 
ent to server with the corresponding response from server to client. The client 
10 may have sent more than one request to the server before it gets the first re- 
sponse back. The first response does not necessarily refer to the first request. 
Therefore there needs to be a mechanism that associates requests and re- 
sponses together. Typically a Transaction ID is a sequence number. It is as- 
signed by the client in the request and used by the server in the response. 

15 

A.1.3 GroupID 

Content Model: (#PCDATA) 
Attributes: None 

Usage: This id uniquely identifies within the service provider domain 
20 the publisher role including the authorisation group and presence set. It is as- 
signed by the presence service provider. 

A. 1.4 UpdateStatus 

Direction: Presence Server -> Presence Client 
25 Content Model: (TransactionID, StatusCode) 

Attributes: None 

Usage: This primitive is the response from the presence server to the 
client UpdatePresence request. The StatusCode may have following values: not 
supported, new allocation, success, failure. 

30 

A. 1.5 GetPresence 

Direction: Presence Client -> Presence Server 

Content Model: (TransactionID, ((GroupID, PresenceNames?)*) | 
PresenceNames?) 
35 Attributes: None 
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Usage: This primitive is used to request presence information from 
the presence server. There may be zero or more GrouplDs. For each GroupID 
there may be coupled an optional PresenceNames. When the GroupID is not 
used then the request scope is all the groups the user is a member. The server 
5 associates the requesting user's identity to the request by the authentication 
protocol. The PresenceNames is defined later in this document. It lists those 
presence items by name from which the value is requested. It is optional. It is ei- 
ther coupled with GrouplDs or may be alone when no GrouplDs are listed. 
When coupled with GrouplDs the server limits the search of the presence items 
10 for the given group. When not present the values of all presence items is re- 
quested. 

A.1.6 Presenceltems 

Direction: Presence Server -> Presence Client 
15 Content Model: (Transaction^, StatusCode, (GroupID, Presence)*) 

Attributes: None 

Usage: This primitive supplies the list of presence items requested 
and the result status of the request. The element Presence is the presence set 
corresponding to a given GroupID and is defined later in this document. The 
20 StatusCode may have following values: not authorised, item not available, suc- 
cess, failure. 

A.2.0 Subscribed Presence (Fig. 9) 

Another mechanism to deliver presence information is to subscribe 
25 someone's presence information. The message flow is presented in Fig. 9. 

The requesting user sends a subscribe presence message A.2.1 to 
the presence server to subscribe someones presence information. 

When the subscription of presence information is complete, the re- 
questing user will receive new presence information A.2.2 initially and always 
30 when the other party updates its presence information. 

When the requesting user does not any more want to receive the 
presence information, he may unsubscribe A.2 the presence information. Alter- 
natively, the presence information may be subscribed to a time period and the 
unsubcribe message is not needed. 
35 The requesting user may subscribe only part of the presence informa- 

tion that he is authorised to get. 
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A.2.1 SubsPresence 

Direction: Presence Client -> Presence Server 
Content Model: (T ransactionID, SubsPeriod?, ((GroupID, Presence- 
5 Names?)*) | PresenceNames?) 

Attributes: None 

Usage: This primitive is used to subscribe presence information from 
publisher roles for which the subscriber is authorised. The optional GroupID 
specifies the publisher role which is subscribed. When the GroupID is missing 

10 then all the roles for which the subscriber is authorised are subscribed. Each 
GroupID may be associated with a PresenceNames which limits the subscribed 
items within the group to those listed in the PresenceNames. The optional Sub- 
sPeriod specifies the length in time for the subscription. When it is missing the 
subscription lasts until an corresponding UnsubsPresence primitive is invoked or 

15 until the service provider terminates subscription. The PresenceNames specifies 
the presence items that are subscribed from the authorised set. When it is miss- 
ing then all the presence items that the user is authorised for within the pres- 
ence set (GroupID) are subscribed. When used alone without a GroupID then 
the named items from all authorised groups are subscribed. PresenceNames is 

20 defined later in this document. 

The identity of the subscriber is discovered in the authentication pro- 
tocol. 

A.2.2 SubsPeriod 
25 Content Model: (#PCDATA) 

Attributes: None 

Usage: This defines the length of the subscription period. The time 
unit is TBD. Alternatively the content may indicate the date when the subscrip- 
tion ends. 

30 

A.2.3 PushPresence 

Direction: Presence Server -> Presence Client 
Content Model: (GroupID, Presence)* 
Attributes: None 
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Usage: This primitive pushes the subscribed presence items that 
have been modified by the publisher to the users. The GroupID identifies the 
role. 

5 A.2.4 UnsubsPresence 

Direction: Presence Client -> Presence Server 
Content Model: (Transaction ID, ((GroupID, PresenceNames?)*) | 
PresenceNames?) 

Attributes: None 

10 Usage: This primitive is used to unsubscribe presence information. 

The termination of subscription may be limited to given groups and can further 
be limited to given presence items. When no GroupID is given it is possible to 
limit the subscription termination for the named presence items in all the groups. 
When no GroupID and no PresenceNames is given then the whole subscription 

15 of the user is terminated. 

A.2.5 SubsStatus . 
Direction: Presence Server -> Presence Client 
Content Model: (Transaction ID, StatusCode, (GroupID, Presence- 

20 Names)*) 

Attributes: None 

Usage: This primitive returns the StatusCode for the unsubscribe op- 
eration and lists the presence items and groups that are still subscribed. The 
StatusCode may have following values: not supported, non-existent item, non- 
25 subscribed item, success, failure. 

A.3.0. Management of Presence Database 

The presence user may manage his user groups and presence sets 
in the presence server. 

30 A ro,e containing a user group and presence set is created using 

CreatePresGroup message A.3.1. The presence server will reply with Pres- 
GroupStatus message A.3.6 indicating the status of the requested operation and 
an id for the created group. A Presencelnfo message A.3.7 is sent to members 
of the group indicating the presence items they are authorised to get or sub- 

35 scribe. 
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The presence user may request group info with the GetPresGroup- 
Status message A.3.8. The group info request is limited to the owner of the , 
group. 

The presence user owning the user group may add and delete mem- 
5 bers of the group or presence items for the presence set. 

The publisher may send delete a group by message DeletePres- 

Group. 



A.3.1 CreatePresGroup 
10 Direction: Presence Client -> Presence Server 

Content Model: (Transaction! D, MemberList, Presence) 
Attributes: None 

Usage: This primitive requests the server to create a role in the pres- 
ence server. The authorisation group contains the members in the memberlist 
15 and the presence set is contained in Presence. 



A.3.2 MemberList 

Content Model: (MemberDescription)+ 
Attributes: None 

Usage: The list of members. The description is originated from the 

user. 



A.3.3 MemberDescription 

Content Model: (UserOriginatedMD?, ServerOriginatedMD?) 
25 Attributes: None 

Usage: The user originated part is a description of a member as seen 
by the user. The server originated part is a description of a member as stored in 
the server database. 

30 A.3.4 UserOriginatedMD 

Content Model: (#PCDATA) 
Attributes: None 

Usage: This is a user originated means to identify a person. It may 
be a name, an MSISDN of one of the phones of the target person, an email ad- 
35 dress, a SIP address etc. It may also be a combination of these. The dataformat 



BNSDOCID. <WO 02093959A1_I_> 



WO 02/093959 



PCT/FI02/00403 



10 



15 



39 

of the description is not within the scope of this document but known formats 
such as vCard should be used. 

A.3.5 ServerOriginatedMD 

Content Model: (#PCDATA) 
Attributes: None 

Usage: This is a server originated means to idenfy a person. It may 
be a name, an MSISDN of one of the phones of the target person, an email ad- 
dress, a SIP address etc. It may also be a combination of these as stored in the 
server database. The dataformat of the description is not within the scope of this 
document but known formats such as vCard should be used. 

A.3.6 PresGroupStatus 

Direction: Presence Server -> Presence Client 

Content Model: (TransactionID, StatusCode, (GroupID, MemberList, 
PresenceNames)*) 

Attributes: None 

Usage: This primitive returns the GrouplD's of the currently existing 
publisher roles together with the group-members and presence item names for 
the role. The server has assigned a new GroupID for the new role if the opera- 
tion was succesfuf. The server has filled the server originated part of the mem- 
berlist. This allows the publisher to verify that the group contains the right mem- 
bers. The server should not give any confidential or personal information in the 
memberlist beyond the level already existing in the user originated part or a level 
that is needed to uniquely identify a person. This is TBD. The StatusCode may 
get following values: not supported, unknown member, unknown presence item, 
success, failure. 

A.3.7 Presencelnfo 
30 Direction: Presence Server -> Presence Client 

Content Model: (GroupID, Presence?)* 
Attributes: None 

Usage: This primitive advertises the new presence items to the au- 
thorisation group. The message contains all the presence items of the given au- 
35 thorisation group - both subscribed and unsubscribed. This message is sent to 
new members in the group if the group membership has changed or to all the 
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members of the group if new presence items have been added. The message is 
sent to removed group members so that there is no presence set (Presence) . 
associated with the GrouplD. 

5 A.3.8 GetPresGroupStatus 

Direction: Presence Client -> Presence Server 
Content Model: (TransactionID, GrouplD*) 
Attributes: None 

Usage: This primitive requests the PresGroupStatus message from 
10 the server. The user may only request info from his own groups. The GrouplD 
limits the info to the given groups. When no GrouplD exist then the status is re- 
turned from all the groups owned by the requestor. 

A.3.9 AddMembers 
15 Direction: Presence Client -> Presence Server 

Content Model: (TransactionID. (GrouplD, MemberList)+) 
Attributes: None 

Usage: This primitive requests the server to add the named members 
into given groups. 

20 

A.3. 1 0 RemoveMembers 

Direction: Presence Client -> Presence Server 

Content Model: (TransactionID, (GrouplD, MemberList)+) 

Attributes: None 

25 Usage: This primitive requests the server to remove the named 

members from the given groups. The MemberList is filled with the server origi- 
nated info. 

A.3.11 DeletePresGroup 
30 Direction: Presence Client -> Presence Server 

Content Model: (TransactionID, GrouplD*) 
Attributes: None 

Usage: This primitive requests the server to remove one or more of 
the publisher roles. The GrouplD identifies the role that is to be removed. When 
35 no GrouplD is given then all the publisher roles are removed. 
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A.3.12 AddPresence 

Direction: Presence Client -> Presence Server 
Content Model: (TransactionlD, (GroupID, Presence)*) 
Attributes: None 

5 Usage: This primitive requests the server to add given presence 

items into given roles. 

A3. 1 3 RemovePresence 

Direction: Presence Client -> Presence Server 
10 Content Model: (T ransactionID, (GroupID, Presence?)*) 

Attributes: None 

Usage: This primitive requests the server to remove given presence 
items from the given roles. When there is no Presence element associated with 
GroupID then all the presence items are removed from the role. 

15 

A.3. 1 4 Dynamic Client Change 

A publisher or subscriber may change his client at any time. Typically 
also the client device changes. In a rare case the user may only change the cli- 
ent instance in the same device. The new device may be a TE and the old a MT 

20 or vice versa. Also change to a new MT is possible. The client change requires 
the user to copy or synchronize his presence data from the old client to the new 
client. In case of a publisher there might be some client specific presence data 
that is static for a given client and is not included in the synchronisation set. The 
synchronisation may take place locally or may be network assisted. In any case 

25 the existing synchronisation protocols should be used. This is not within the 
scope of the presence protocol. 

Another issue brought by the subscriber client change is the registry 
of the new client to be the active client that receives the presence related push 
messages. The registry may take place automatically (no user confirmation 

30 needed), semi-automatically (user confirmation required) or manually (user must 
initiate the registry) depending whether 

- User activates a new client in the same device (automatic); 

- User SIM changes to the new device (automatic); 

- User has a different SIM in the new device but only the new device 
35 is turned on (semi-automatic); or 
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- User has a different SIM in the new device and both the new device 
and old device are on (manual). 

In all the cases the registry may be handled by lower level protocols. 
For example if the SIP-protocol is the chosen transport protocol for presence 
5 documents then this protocol can also be used for the registry. 

A.4.0 DTD for the Presence Protocol 

<!- Root element -> 

10 

<!ELEMENT PresProtocol ( UpdatePresence | UpdateStatus | Get- 
Presence | Presenceltems | SubsPresence | PushPresence | UnsubsPrecence | 
SubsStatus | CreatePresGroup | PresGroupStatus | Presencelnfo | GetPres- 
GroupStatus | AddMembers | RemoveMembers | DeletePresGroup | AddPres- 
15 ence | RemovePresence) > 

<!ATTLIST PresProtocol Version NMTOKENS #REQUIRED > 

<!ELEMENT UpdatePresence (TransactionID, GroupID, Presence) > 

20 

<!ELEMENT TransactionID (#PCDATA) > 
<!ELEMENT GroupID (#PCDATA) > 
25 <!ELEMENT Presence (#PCDATA) > 

<!ELEMENT UpdateStatus (TransactionID, StatusCode) > 
<!ELEMENT StatusCode (#PCDATA) > 

30 

<!ELEMENT GetPresence (TransactionID, ((GroupID, 
PresenceNames?)*) | PresenceNames?) > 

<!ELEMENT PresenceNames (#PCDATA) > 

35 

<!ELEMENT Presenceltems (TransactionID, StatusCode, (GroupID, 
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Presence)*) > 

<!ELEMENT SubsPresence (TransactionID, SubsPeriod?, ((GroupID, 
PresenceNames?)*) | PresenceNames?) > 

<!ELEMENT SubsPeriod (#PCDATA) > 

<!ELEMENT PushPresence ((GroupID, Presence)*) > 

<!ELEMENT Unsubs Presence (TransactionID, ((GroupID, 
PresenceNames?)*) | PresenceNames?) > 

<!ELEMENT SubsStatus (TransactionID, StatusCode, (GroupID, 
PresenceNames)*) > 

<!ELEMENT CreatePresGroup (TransactionID, MemberList, 
Presence) > 

<!ELEMENT MemberList ((MemberDescription)+) > 

( <!ELEMENT MemberDescription (UserOriginatedMD?, 
SeiverOriginatedMD?) > 

<! ELEMENT UserOriginatedMD (#PCDATA) > 

<!ELEMENT SeiverOriginatedMD (#PCDATA) > 

<!ELEMENT PresGroupStatus (TransactionID, StatusCode, 
(GroupID, MemberList, PresenceNames)*) > 

<!ELEMENT Presencelnfo ((GroupID, Presence?)*) > 

<!ELEMENT GetPresGroupStatus (TransactionID, GroupID*) > 

<!ELEMENT AddMembers (TransactionID, (GroupID, MemberList)*) 
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<! ELEMENT RemoveMembers (TransactionID, (GroupID, 
MemberList)+) > 

5 <!ELEMENT DeletePresGroup (TransactionID, GroupID*) > 

<!ELEMENT AddPresence (TransactionID, (GroupID, Presence)*) > 

<!ELEMENT RemovePresence (TransactionID, (GroupID, 
10 Presence?)*) > 

<!-- End of DTD -> 

B. EXEMPLARY PRESENCE CONTENT FORMAT 

As stated above, the presence content can be divided in the following 

15 classes: 

Client Availability: Presence attributes describing the availability of the 
client for communication, for instance, network reachability, GPRS attached, 
on/off status. 

User Availability: Presence attributes describing the availability of the 
20 user for communication, for instance, ready, meeting, busy, away, in call, chat- 
ting, dont disturb, etc. 

Local Conditions: Presence attributes describing the local environ- 
ment at the user, for instance, local time, noisy/silent environment, in-door, out- 
door, location of the user, in terms of, for instance, geographical location, visited 
25 PLMN, city/street, premises. 

Personal Status: Various personal attributes describing personal user 
status, for instance, mood, personal interests and intentions. 

Client Capabilities: Presence attributes describing the capabilities of 
the client, for instance, to support different means of communication, different 
30 media types and different features. 

User Attributes: Presence attributes allowing the client or the user to 
define their own textual presence values and references to external values. 

Extended Presence Service: Service provider dynamically defined 
non-standard presence attributes which however need to be passed through 
35 standard presence servers and proxies. 



02093959A1 I > 



WO 02/093959 PCT/FI02/00403 

45 

B.1. DESIGN GOALS 

The bulk of presence communication is sending the changes in the 
value part of presence items to the subscribers. Often only a single value has 
changed. In order to minimize the amount of transferred data the design goal is 
5 to keep the hierarchical representation of presence items as flat as possible. For 
this reason the presence items are scoped under the presence classes de- 
scribed above. Instead the classes may be given in the presence items as an 
optional attribute. 

10 D.2 COMMON ATTRIBUTES 

The presence elements contain a variety of attributes most of which 
can be used in any presence item. 

D.2.1 Version 

1 5 Content Syntax: NMTOKENS 

Mandatory: yes 

Usage: This gives the version of the presence content format 

D.2.2 Class 
20 Content Syntax: NMTOKEN 

Mandatory: no 

Usage: This indicates the class the attribute belongs to. 

Possible values are: CLIENT_AVAILABILITY, 
USER_AVAILABILITY, LOCAL_CONDITIONS, 
25 PERSONAL_STATUS, CLIENT_CAPABILITIES, 

USER_ATTRIBUTES, EXT_PRES_SERVICE. 

D.2.3 ID 

Content Syntax: PUBIDLITERAL 
30 Mandatory: no 

Usage: This is a unique ID for a named presence item. It is 
assigned by the client. 

D.2.4 Cacheability 
35 Content Syntax: NMTOKEN 

Mandatory: no 
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Usage: This indicates whether the presence item can be 
cached by proxies or not. The possible values are: . 
YES, NO.lt is assigned by the client. If this attribute is 
missing a value of NO is assumed. 

5 

D.2.5 ValidityPeriod 

Content Syntax: NMTOKEN 
Mandatory: no 

Usage: This is a validity period for the cached presence item. 
10 The value is time in seconds. It is assigned by the 

presence server. 



D.2.6 DeviceName 

Content Syntax: NMTOKEN 
15 Mandatory: no 

Usage: This is the name of the client device. It is assigned by 
the client. 

D.2.7 Accuracy 
20 Content Syntax: NMTOKEN 

Mandatory: no 

Usage: This is the accuracy of a positioning device. It is given 
in meters. 



25 D.2.8 ImageType 

Content Syntax: NMTOKEN 
Mandatory: no 

Usage: This is the content encoding of an image. Some 
possible values are: JPEG, GIF, BMP. 

30 

D.2.9 SoundType 

Content Syntax: NMTOKEN 
Mandatory: no 

Usage: This is the type of sound codec used to encode the 
35 sound. Some possible values are: AMR, EFR, MP3, 

AAC, MIDI 
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D.2.10 ExtRef 

Content Syntax: PUBIDLITERAL 
Mandatory: no 

5 Usage: This is a URL giving an external reference. 

D.2.11 ExtRef Change 

Content Syntax: NMTOKEN 
Mandatory: no 

10 Usage: This indicates that the content of an external reference 

has changed. The possible values are: YES, NO 

D.2.12 ContentChange 

Content Syntax: NMTOKEN 
15 Mandatory: no 

Usage: This is a counter from 0 to 255 which indicates a 

change in the content value. The server or proxy may 
store the contents (but is not required to) of the last 32 
values. Same values for two contents within the last 32 
values should correspond to same content 



20 



D.3 Client Availability 

D.3.1 DeviceOn 
25 Content Model: (#PCDATA) 

Attributes: Class, ID, Cacheability, ValidityPeriod, DeviceName 
Usage: This gives the on/off status of the user terminal. The 
publisher adds this item into the role in the server by 
using the group management messages. Thereafter the 
value part is maintained by the network. The user may 
have more than one terminal in his presence 
information. * In this case the use of ID attribute is 
mandatory. The content can have values "ON" or 
"OFF". When the user's terminal is on but outside 
network coverage the network assigns value "OFF" for 
this item. 



30 



35 
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10 



15 



D.3.2 DeviceRoaming 

Content Model: (#PCDATA) 

Attributes: Class, ID, Cacheability, ValidityPeriod, DeviceName 
Usage: This indicates to the subscriber that the publisher is 
roaming in a visited network. The user may have more 
than one terminal in his presence information. In this 
case the use of ID attribute is mandatory. The content 
can have values "YES" or "NO" 

D.3.3 NetworkType 

Content Model: (#PCDATA) 

Attributes: Class, ID, Cacheability, ValdityPeriod, DeviceName 
Usage: This indicates the type of mobile network the publisher 
is currently attached. The content can have values 
"2G", "3G-99", "3G-R4" or "3G-R5". The user may have 
more than one terminal in his presence information. In 
this case the use of ID attribute is mandatory. 

20 D.4 User Availability 

D.4.1 UserStatus 

Content Model: (#PCDATA) 
Attributes: Class, ID, Cacheability, ValidityPeriod 
25 Usage: This indicates the current status of the publisher in 

terms of amount of distraction he is willing to accept. 
The following values are defined: "available", "silent", 
"in-car", "busy". 

30 D.4.2 PreferredContact 

Content Model: (#PCDATA) 
Attributes: Class, ID, Cachebility, ValidityPeriod 
Usage: This indicates what is the current preferred contact 
method for the publisher. Following values are defined: 
35 "PHONE", "VOICE_MESSAGE", "MESSAGE", "MAIL", 

"NO CONTACT'. 
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D.4.3 Preferred Defaults 

Content Model: ((TimePeriod, PrefCont)*) 
Attributes: Class, ID, Cacheabillty, ValidityPeriod 
Usage: This is presence metalnformation that the publisher 
may send to presence server. The information is 
associated to a role as other presence information but 
this item is not available to subscribers. Instead it 
controls the values of the element 'PreferredContacf. It 
specifies a default preferred contact for given time 
periods. User specified time periods may overlap or a 
time period may even completely enclose another. The 
server changes the value of PreferredContacf element 
according to the Preferred Defaults at the expiration of 
15 given periods. It however does not block a user 

changing the PreferredContacf value directly. Also the 
user changing the PreferredContact value directly does 
not block the server changing it again when a period 
expires. The user may remove the default mechanism 
by sending this element with empty contents to the 
server. 



10 



20 



D.4.4 TimePeriod 

Content Model: (PeriodStart, PeriodEnd, RepetitionPeriod?, Period- 
25 Precedence) 

Attributes: None 

Usage: This desribes the start of a period e.g. start time, the 
end of the period e.g. end time, the repetion period e.g. 
'DAV and the presedence of the period. 

30 

D.4.5 PeriodStart 

Content Model: (#PCDATA) 
Attributes: None 

Usage: This is the start period. It may be Time, Time- 
35 DayofWeek, Time-DayofMonth or a full date.. 
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D.4.6 PeriodEnd 

Content Model: (#PCDATA) 
Attributes: None 

Usage: This is the start period. It may be Time, Time- 
5 DayofWeek, Time-DayofMonth or a full date. The 

resolution must be the same as in PeriodStart. 

D.4.7 RepetitionPeriod 

Content Model: (#PCDATA) 
10 Attributes: None 

Usage: This gives the repetition period for the start-end. It must 
be one of the following values: "DAY", "WEEK", 
"MONTH". When this element is not included in the 
period description then it is assumed that no repetion is 
15 applied. 

D.4.8 Period Precedence 

Content Model: (#PCDATA) 
Attributes: None 

20 Usage: This element resolves the conflict between overlapping 

periods. It can have a numeric value between 0 and 9. 
Number 0 is the highest precedence. When two or 
more periods overlap then the server takes the contact 
preference associated with the highest precedence 

25 value. 

D.4.9 PrefCont 

Content Model: (#PCDATA) 
Attributes: None 

3 0 Usage: This indicates what is the period associated default 

preferred contact method for the publisher. It can have 
the same values as the element 'PreferredContact'. 

D.5 Local Conditions 

35 
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LocalTime 

Content Model: (#PCDATA) 

Attributes: Class, ID, Cacheability, ValidityPeriod 

Usage: This gives the local time of the publisher 

MeasuredLocation 
Content Model: (#PCDATA) 

Attributes: Class, ID, Cacheability, ValidityPeriod, Accuracy 
Usage: This gives the measured position of the client device. 

The measurements may be either sensor based (e.g. 
GPS) or network based or combination of both. The 
attibute Accuracy gives indication of the average 
positioning accuracy achieved by the method. The 
content includes at least the lateral position (x- and y- 
coordinates) but may include also the vertical position. 
If the service provider supports 'Converted Location' 
described below then the MeasuredLocation may be 
input Information for the service provider conversion 
process e.g. map matching. 

ConvertedLocation 

Content Model: (#PCDATA) 

Attributes: Class, ID, Cacheability, ValidityPeriod 

Usage: This information is typically originated from the service 
provider but may also originate from the publisher. It 
gives the location of the user given in a human 
understandable text form such as a name of a street. 
The information is derived by converting a measured 
position into this form by e.g. map matching. 

StatedLocation 
Content Model: (#PCDATA) 
Attributes: Class, ID, Cacheability, ValidityPeriod 
Usage: This is the location of the publisher as stated by the 
publisher himself. The content is a short text string. 
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D.5.5 UserEnvironment 

Content Model: (EnvAttributes+) 
Attributes: Class, ID, Cacheability, ValidityPeriod 
Usage: This gives some environmental attributes about the 
5 user. 

D.5.6 EnvAttributes 

Content Model: (#PCDATA) 
Attributes: None 

10 Usage: The attributes defined are: "INDOOR", "OUTDOOR", 

"QUIET", "NOISY", "ALONE", "IN_GROUP". 

D.6 Personal Status 

15 D.6.1 StatusText 

Content Model: (#PCDATA) 
Attributes: Class, ID, Cacheability, ValidityPeriod 
Usage: This is a short text (about 30 characters) that the user 
may write. 

20 

D.6.2 Status I mage 

Content Model: (#CDATA) 

Attributes: Class, ID, Cacheability, ValidityPeriod, ImageType 
Usage: This is an image the user may attach to his status 
information. It is earned in the XML content in a transfer 
encoded form e.g. base64. The ImageType attribute 
describes the content encoding of the image e.g. jpeg. 

D.6.3 StatusSound 
30 Content Model: (#CDATA) 

Attributes: Class, ID, Cacheability, ValidityPeriod, SoundType 
Usage: This is a short (about 5 to 30 seconds) sound clip the 
user may attach to his status information. It is carried in 
the XML content in a transfer encoded form e.g. 
35 base64. The SoundType attribute describes the content 

encoding of the sound e.g. AMR, MP3, AAC, MIDI etc. 
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D.7 Client Capabilities 

The client capabilities in the context of presence mean the capability 
of the device hosting the client for various types of human to human 
5 communication. This is very much different and simpler issue than 

the case of allowing an application software to take maximum advan- 
tage of the existing hw and sw capabilities of the client device. 

The classes of human to human communication are: messaging, e- 
mail, voice call and multimedia call. In particular presence is excluded 
10 from the communication classes. The purpose of presence is to make 

others aware of the communication means and other user attributes 
but not to be a two way communication means itself. For this reason 
the use of the term 'Client Capabilities' to classify presence infor- 
mation is somewhat misleading. 

15 Tne client capabilities are scoped with the network capabilities. This 

means for example that the publisher has the video call capability 
only when his client device has this capability AND the network he is 
currently roaming supports this capability. This makes the client 
capability information dynamic. 

20 

D.7.1 MessagingCapabilities 

Content Model: (MessType*) 
Attributes: Class, ID, Cacheability, ValidityPeriod 
Usage: This gives the dynamic messaging capability list of the 
client device. An empty list means that no messaging 
capabilities currently exist. 



25 



D.7.2 MessType 

Content Model: (#PCDATA) 
30 Attributes: None 

Usage: This gives the messaging capability type of the client 
device. The content may be one of the following: 
"SMS", "MMS" or n X -messaae application name ". The 
field message application nama is a device specific 
35 messaging method e.g. smart messaging. 
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D.7.3 EmailClient 

Content Model: (EmailClientType*) 
Attributes: Class, ID, Cacheability, ValidityPeriod 
Usage: This gives the dynamic e-mail capabilities of the client 
5 device. An empty list means that no e-mail capabilities 

currently exist. 

D.7.4 EmailClientType 

Content Model: (#PCDATA) 
10 Attributes: None 

Usage: This gives the e-mail client type of the client device. 

The content may be one of the following: "SMTP", 
"POP3", "IMAP4" or "X-mail application name". The 
client software should not render the mail protocol 
15 names as such to the user. Instead the client software 

should understand the user device email environment 
and interpret these names in the scope of this email 
environment. The information presented to the user 
should be alsoTneaningful to the user. 

20 

D.7.5 VoiceCallCapability 

Content Model: (#PCDATA) 
Attributes: Class, ID, Cacheability, ValidityPeriod 
Usage: This gives the dynamic voice call capabilities of the 
25 client device. The content is one of the following: 

"NONE", "VOICE_CALL", "RICH_VOICE_CALL". 

D.7.6 MultimediaCallCapabilities 
Content Model: (MMCap*) 
30 Attributes: Class, ID, Cacheability, ValidityPeriod 

Usage: This gives the dynamic one-way and two-way 

multimedia communication capabilities of the user. An 
empty list indicates that no capabilities currently exist. 

35 D.7.7 MMCap 

Content Model: (#PCDATA) 
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Attributes: None 

Usage: This gives the multimedia call capability type. It may be 
one of the following: "UPLINK_VIDEO_STREAMING", 
"DOWNLINK_VIDEO_STREAMING", 'VIDEO^CALL", 
5 n RICH_VIDEO_CALL". 

D.8 User Attributes 

This class contains both user defined and client specific presence 
data. 

10 

D.8.1 UserPresenceltem 

Content Model: (#PCDATA) 

Attributes: Class, ID, Cacheability, ValidityPeriod, ExtRef, ExtRef- 

Change 

15 Usage: This gives a means for the user to defined their own 

presence items. If more than one user specified 
presence item is defined for the same role then the use 
of ID attribute is mandatory. The content may be a short 
text. The optional attribute ExtRef is a URL of an 

20 external object referenced by this presence item. The 

URL may refer to another part of the multipart MIME 
that carries the XML-document of the presence item or 
it may be a reference to an external object. The 
optioanal attribute ExtRefChange may be used to 
25 indicate the subscribers that the external object has 

changed. 

D.8.2 ClientTypeRequest 

Content Model: (EMPTY) 
30 Attributes: Class, ID, Cacheability, ValidityPeriod 

Usage: This is a special element used by the publisher to 
request the client types of his subscribers. When a 
publisher includes this element into his presence data 
for a given role then the server sends this to all the 
35 subscribers of the presence information with the 

PushPresence message. Optionally it may also be 
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included in the Presenceltems message used by non- 
subscribers to request specific presence items. This , 
element is not advertised in the Presencelnfo message. 
It is not a presence element that can be subscribed to. 
The presence server after having first time sent this 
item to the subscribers may periodically include this 
item also to further PushPresence messages to make 
sure that all the subscriber clients have this item. 
The clients upon receiving this item send their client types to the 
presence server. In addition a client should send it's type to the 
server every time the client is activated when this item is the pres- 
ence info stored in the client. 

An alternative way of the publisher getting to know the client types of 
his subscribers would have been for the publisher to subscribe their 
client types. This however is a different business model. A publisher 
may not always want to be a subscriber of his own subscribers. This 
element allows the publisher to get the client types within the existing 
contractual frame between the publisher and the presence service 
provider. In addition this method mandates the subscriber client to 
send their types to the server. If the publisher would have used the 
subscription model to get the client types then the authorisation of 
this information to the publisher would have been at the discretion of 
the subscriber. 

D.8.3 ClientType 

Content Model: (ClientName, ClientManufacturer, ClientVersion) 
Attributes: Class, ID, Cacheability, ValidityPeriod 
Usage: Knowledge of the subscriber client types is used by 
publishers to enable client specific extensions to the 
presence set. It does not make sense for a publisher to 
use these extension items if his subscriber clients are 
not able to decode them. 
A subscriber client sends the cliend type info to the presence server 
using the UpdatePresence message. The GroupID used in the 
message belongs to the publisher's role and not to the subsriber"s 
own role. This is an exception from the general rule that a user is 
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allowed to update the presence information of his own role only. The 
presence server sends the information of this element to the pub- 
lisher using the PushPresence message. The GroupID used belongs to the pub- 
lisher role. From the publisher point of view then he is getting presence informa- 
5 tion from his own presence set. 

A publisher may include his own client type into his presence set. 
Then this information is handled like any other presence information 
and does not imply any special behaviour in presence servers or 
subsciber clients. 

10 

D.8.4 ClientName 

Content Model: (#PCDATA) 
Attributes: None 

Usage: This element gives the name of the presence client 
15 application 

D.8.5 ClientManufacture 

Content Model: (#PCDATA) 
Attributes: None 

20 Usage: This element gives the name of the presence client 

manufacture 

D.8.6 ClientVersion 

Content Model: (#PCDATA) 
25 Attributes: None 

Usage: This element gives the version of the client application. 

D.8.7 ClientPresenceltem 

Content Model: (ClientType, CliPresltem) 
30 Attributes: Class, ID, Cacheability, ValidityPeriod, ContentChange 

Usage: This element is the publisher client application specific 
presence item. The ClientType is the client type of the 
publisher's presence client. No attributes are used in 
the ClientType Item when used as part of this element. 
35 If the publisher defines more than one client specific 

presence item then the use of the ID attribute is 
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mandatory. The optional attribute ContentChange is a 
counter from 0 to 255. When used it is increased by' 
one every time the content of the presence item 
changes. This provides an alternative means for the 
5 presence server to detect change in the content of a 

non-standard presence item. The other alternative 
would have been for the presence server to assume 
that the content changes every time this item is sent to 
the server with the same ID attribute. The server 
10 behaves in this way when the ContentChange attribute 

is not used by the client. When two items with the same 
ID attribute have the same counter value in 
ContentChange then the content of these two items is 
the same. 

15 

D.8.8 CliPresltem 

Content Model: (#PCDATA) 
Attributes: None 

Usage: This element is the client specific presence extension. 
20 It's syntax and structure is assumed to be known to the 

client but not to the network elements. 

D.9 Extended Presence Service 

The extended presence service class is meant to provide a service 

25 provider specific extension to the presence service. Like the client 

application specific extension only the service end points (i.e. the 
publisher and the subscriber clients) need to be able to decode the 
extensions. It is possible that the presence server also understands 
the extensions but this is not mandated by this document The 

30 difference between the client specific extension method and this 

method is that the service provider controlled clients do not need to 
implement the standard presence items. It is assumed that the 
presence items are completely defined by the service provider and 
there is a means to update the user device hosted clients with new 

35 features. One possible update method is sw downloading via air. If a 

service provider creates new types of presence items then he needs 
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to update the existing clients to support these new types. The service 
provider controlled client communicates with the presence server 
directly and not via a standard presence client. A standard presence 
client ignores all elements of this class. 

An extended presence service uses primarily the elements of this 
class. It is allowed to use also the standard presence element defini- 
tions. It uses the standard presence protocol. 

ExtPresence 

Content Model: (#PCDATA) 

Attributes: Class, ID, Cacheability, ValidityPeriod, ContentChange 
Usage: The use of ID attribute is mandatory if more than one 
presence item is defined by this mechanism. The 
optional ContentChange attribute is available also for 
this element. The syntax and representation of the 
contents are not in the scope of this document. The 
presence servers and proxies should allow the contents 
to refer to objects carried in the same multipart MIME 
as the XML-documents containing this element. 

DTD for the presence content format 
<!- Root element -> 

<!ELEMENT Presence ( DeviceOn | DeviceRoaming | NetworkType | 
UserStatus | PreferredContact | Preferred Defaults | LocalTime | MeasuredLoca- 
tion | ConvertedLocation | StatedLocation | UserEnvironment | StatusText | 
Statuslmage | StatusSound | MessagingCapabilities | EmailClient | VoiceCall- 
Capability | MultimediaCallCapabilities | UserPresenceltem | ClientTypeRequest 
30 I ClientType | ClientPresenceltem | ExtPresence) > 

<!ATTLIST Presence Version NMTOKENS #REQUIRED > 



D.9.1 

10 



15 



20 

D.10 



35 



<!ELEMENT DeviceOn (#PCDATA) > 
OATTLIST DeviceOn 
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Class NMTOKEN #IMPLIED 
ID PUBIDLITERAL #IMPL1ED 
Cacheability NMTOKEN #IMPLIED 
ValldityPerlod NMTOKEN #IMPLIED 
DeviceName NMTOKEN #IMPLIED > 

<!ELEMENT DeviceRoaming (#PCDATA) > 

<!ATTLIST DeviceRoaming 

Class NMTOKEN #IMPLIED 
ID PUBIDLITERAL #IMPLIED 
Cacheability NMTOKEN #IMPLIED 
ValidityPeriod NMTOKEN #IMPLIED 
DeviceName NMTOKEN #IMPLIED > 

<!ELEMENT NetworkType (#PCDATA) > 

<!ATTLIST NetworkType 

Class NMTOKEN #IMPLIED 
ID PUBIDLITERAL #IMPLIED 
Cacheability NMTOKEN #IMPLIED 
ValidityPeriod NMTOKEN #IMPLIED 
DeviceName NMTOKEN #IMPLIED > 
25 

<!ELEMENT UserStatus (#PCDATA) > 

<!ATTLIST UserStatus 

30 Class NMTOKEN #IMPLIED 

ID PUBIDLITERAL #IMPLIED 
Cacheability NMTOKEN #IMPLIED 
ValidityPeriod NMTOKEN #IMPLIED > 

35 <!ELEMENT PreferredContact (#PCDATA) > 



10 



15 
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<!ATTLIST PreferredContact 

Class NMTOKEN #IMPLIED 
ID PUBIDLITERAL #IMPLIED 
5 Cacheability NMTOKEN #IMPLIED 

ValidltyPeriod NMTOKEN #IMPLIED > 

<!ELEMENT PreferredDefaults ((TimePeriod, PrefCont)*) > 
10 <!ATTLIST PreferredDefaults 

Class NMTOKEN #IMPLIED 
ID PUBIDLITERAL #IMPLIED 
Cacheability NMTOKEN #IMPLIED 
15 ValidityPeriod NMTOKEN #IMPLIED > 

<!ELEMENT TimePeriod (PeriodStart, PeriodEnd, 

RepetitionPeriod?, Period Precedence) > 

20 <!ELEMENT PeriodStart (#PCDATA) > 

<!ELEMENT PeriodEnd (#PCDATA) > 

<!ELEMENT RepetitionPeriod (#PCDATA) > 

<!ELEMENT PeriodPrecedence (#PCDATA) > 

<! ELEMENT PrefCont (#PCDATA) > 

30 <!ELEMENT LocalTime (#PCDATA) > 

<»ATTLIST LocalTime 

Class NMTOKEN #IMPLIED 
35 ID PUBIDLITERAL IMPLIED 

Cacheability NMTOKEN #IMPLIED 



25 
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VafidityPeriod NMTOKEN #IMPLIED > 

<!ELEMENT MeasuredLocation (#PCDATA) > 

5 <!ATTLIST MeasuredLocation 

Class NMTOKEN #IMPLIED 
ID PUBIDLITERAL #IMPLIED 
Cacheabllity NMTOKEN #IMPLIED 
10 Valid ityPeriod NMTOKEN #IMPLIED 

Accuracy NMTOKEN #IMPLIED > 

<!ELEMENT Converted Location (#PCDATA) > 

1 5 <!ATTLI ST ConvertedLocation 

Class NMTOKEN #IMPLIED 
ID PUBIDLITERAL #IMPLIED 
Cacheability NMTOKEN #IMPLIED 
20 ValidityPeriod NMTOKEN #IMPLIED > 

<!ELEMENT StatedLocation (#PCDATA) > 

<!ATTLIST StatedLocation 



25 



30 



Class NMTOKEN #IMPLIED 
ID PUBIDLITERAL #IMPLIED 
Cacheability NMTOKEN #IMPLIED 
ValidityPeriod NMTOKEN #IMPLIED > 

<!ELEMENT UserEnvironment (EnvAttributes+) > 

<!ATTLIST UserEnvironment 



35 Class NMTOKEN #IMPLIED 

ID PUBIDLITERAL #IMPLIED 
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Cacheability NMTOKEN #IMPLIED 
ValidltyPeriod NMTOKEN #IMPLIED > 

<!ELEMENT EnvAttributes (#PCDATA) > 

<!ELEMENT StatusText (#PCDATA) > 

<!ATTLIST StatusText 

Class NMTOKEN #IMPLIED 
ID PUBIDLITERAL #IMPLIED 
Cacheability NMTOKEN #IMPLIED 
ValidityPeriod NMTOKEN #IMPLIED > 

<! ELEMENT Statuslmage (#CDATA) > 

<!ATTLIST Statuslmage 

Class NMTOKEN #IMPLIED 
ID PUBIDLITERAL IMPLIED 
Cacheability NMTOKEN #IMPLIED 
ValidityPeriod NMTOKEN #IMPLIED 
ImageType NMTOKEN #IMPLIED > 

<!ELEMENT StatusSound (#CDATA) > 

<!ATTLIST StatusSound 

Class NMTOKEN #IMPLIED 
ID PUBIDLITERAL #IMPLIED 
Cacheability NMTOKEN #IMPLIED 
ValidityPeriod NMTOKEN #IMPLIED 
SoundType NMTOKEN #IMPLIED > 

<JELEMENT MessagingCapabilities (MessType*) > 
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<!ATTLIST MessagingCapabilities 



Class NMTOKEN #IMPLIED 
ID PUBIDLITERAL #IMPLIED 
Cacheability NMTOKEN #IM PLIED 
ValidityPeriod NMTOKEN #IMPLIED > 



<!ELEMENT MessType (#PCDATA) > 



<!ELEMENT EmailCllent (EmailClientType*) > 



<!ATTLIST EmailClientType 

Class NMTOKEN #IMPLIED 
! 5 ID PUBIDLITERAL #IMPLIED 

Cacheability NMTOKEN #IMPLIED 
ValidityPeriod NMTOKEN #IMPLIED > 



20 



<!ELEMENT EmailClientType (#PCDATA) > 
<!ELEMENT VoiceCallCapability (#PCDATA) 



<!ATTLIST VoiceCallCapability 



Class NMTOKEN #IMPLIED 
ID PUBIDLITERAL #IMPLIED 
Cacheability NMTOKEN #IMPLIED 
ValidityPeriod NMTOKEN #IMPLIED > 



<!ELEMENT MultimediaCallCapabilities (MMCap*) > 



<!ATTLIST MultimediaCallCapabilities 



Class NMTOKEN #IMPLIED 
ID PUBIDLITERAL #IMPLIED 
Cacheability NMTOKEN #IMPLIED 
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ValidityPeriod NMTOKEN #IMPLIED > 
<!ELEMENT MMCap (#PCDATA) > 
5 <!ELEMENT UserPresenceltem (#PCDATA) > 

<!ATTLIST UserPresenceltem 

Class NMTOKEN #IMPLIED 
10 ID PUBIDLITERAL #IMPLIED 

Cacheabllity NMTOKEN #IMPLIED 
ValidityPeriod NMTOKEN #IMPLIED 
ExtRef PUBIDLITERAL #IMPLIED 
ExtRefChange NMTOKEN #IMPLIED > 

15 

<!ELEMENT ClientTypeRequest (EMPTY) > 
<!ATTLIST ClientTypeRequest 

20 Class NMTOKEN #IMPLIED 

ID PUBIDLITERAL #IMPLIED 
Cacheability NMTOKEN #IMPLIED 
ValidityPeriod NMTOKEN #IMPLIED > 



25 



sion) > 



<!ELEMENT ClientType (ClientName, ClientManufacturer, ClientVer- 



<!ATTLIST ClientType 



30 Class NMTOKEN #IMPLIED 

ID PUBIDLITERAL IMPLIED 
Cacheability NMTOKEN #IMPLIED 
ValidityPeriod NMTOKEN #IMPLIED > 

35 <! ELEMENT ClientName (#PCDATA) > 
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<!ELEMENT ClientManufacture (#PCDATA) > 
<!ELEMENT ClientVersion (#PCDATA) > 
5 <!ELEMENT ClientPresenceltem (ClientType, CliPresltem) > 

<!ATTLIST ClientPresenceltem 

Class NMTOKEN #IMPLIED 
10 ID PUBIDLITERAL #IMPLIED 

Cacheability NMTOKEN #IMPLIED 
ValidityPeriod NMTOKEN #IMPLIED 
ContentChange NMTOKEN #IMPLIED > 

1 5 <!ELEMENT CliPresltem (#PCDATA) > 

<!ELEMENT ExtPresence (#PCDATA) > 

<!ATTLIST ExtPresence 

20 

Class NMTOKEN #IMPLIED 
ID PUBIDLITERAL #IMPLIED 
Cacheability NMTOKEN #IMPLIED 
ValidityPeriod NMTOKEN #IMPLIED 
25 ContentChange NMTOKEN #IMPLIED > 

<!- End of DTD -> 
D.11 DTD for PresenceNames 

30 

The DTD for PresenceNames is the same as for Presence except 
that only the presence item names and attributes are included. No presence 
values are used. 

35 <!- Root element -> 
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<!ELEMENT PresenceNames ( DeviceOn | DeviceRoaming | Net- 
workType | UserStatus | PreferredContact | PreferredDefaults | LocalTime | 
MeasuredLocation | ConvertedLocation j StatedLocation | UserEnvironment | 
StatusText | Statuslmage | StatusSound | MessagingCapabilities | EmailClient | 
5 VoiceCallCapability | MultimediaCallCapabilities J UserPresenceltem | Client- 
TypeRequest | ClientType | ClientPresenceltem | ExtPresence) > 

<!ATTLIST PresenceNames Version NMTOKENS #REQUIRED > 

10 <!ELEMENT DeviceOn (EMPTY) > 

<!ATTLIST DeviceOn 

Class NMTOKEN #IMPL(ED 
ID PUBIDLITERAL #IMPLIED 
1 5 Cacheability NMTOKEN #IMPLIED 

ValidityPeriod NMTOKEN #IMPLIED 
DeviceName NMTOKEN #IMPLIED > 

<!ELEMENT DeviceRoaming (EMPTY) > 

20 

<!ATTLIST DeviceRoaming 

Class NMTOKEN #IMPLIED 
ID PUBIDLITERAL #IMPLIED 
25 Cacheability NMTOKEN #IMPLIED 

ValidityPeriod NMTOKEN #IMPLIED 
DeviceName NMTOKEN #IMPLIED > 

<!ELEMENT NetworkType (EMPTY) > 

30 

<!ATTLIST NetworkType 

Class NMTOKEN #IMPLIED 
ID PUBIDLITERAL #JMPLIED 
35 Cacheability NMTOKEN #IMPLIED 

ValidityPeriod NMTOKEN #IMPLIED 
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DeviceName NMTOKEN #IMPLIED > 

<IELEMENT UserStatus (EMPTY) > 

5 <!ATTLIST UserStatus 

Class NMTOKEN #IMPLIED 
ID PUBIDLITERAL #IMPLIED 
Cacheabillty NMTOKEN #IMPLIED 
10 ValidltyPeriod NMTOKEN #IMPLIED > 

<!ELEMENT PreferredContact (EMPTY) > 

<!ATTLIST PreferredContact 



15 



20 



Class NMTOKEN #IMPLIED 
ID PUBIDLITERAL #IMPLI ED 
Cacheabillty NMTOKEN #IMPLIED 
ValidltyPeriod NMTOKEN #IMPLIED > 

<!ELEMENT Preferred Defaults (EMPTY) > 

<!ATTLIST PreferredDefaults 



25 Class NMTOKEN #IMPLIED 

ID PUBIDLITERAL #IMPLIED 
Cacheabillty NMTOKEN #IMPLIED 
ValidltyPeriod NMTOKEN #IMPLIED > 

30 <!ELEMENT LocalTime (EMPTY) > 

<!ATTLIST LocalTime 

Class NMTOKEN #IMPLIED 
35 ID PUBIDLITERAL #IMPLIED 

Cacheability NMTOKEN #IMPLJED 
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ValidityPeriod NMTOKEN #IMPLIED > 
<!ELEMENT MeasuredLocation (EMPTY) > 
5 <!ATTL!ST MeasuredLocation 

Class NMTOKEN #IMPLIED 
ID PUBIDLITERAL #IMPLIED 
Cacheabillty NMTOKEN #IMPLIED 
10 ValidityPeriod NMTOKEN #IMPLIED 

Accuracy NMTOKEN #IMPLIED > 

<!ELEMENT Converted Location (EMPTY) > 

15 <!ATTLIST ConvertedLocation 

Class NMTOKEN #IMPLIED 
ID PUBIDLITERAL #IMPLIED 
Cacheability NMTOKEN #IMPLIED 
ValidityPeriod NMTOKEN #IMPLIED > 

<!ELEMENT StatedLocation (EMPTY) > 

<!ATTLIST StatedLocation 

Class NMTOKEN #IMPLJED 
ID PUBIDLITERAL #IMPLIED 
Cacheability NMTOKEN #IMPLIED 
ValidityPeriod NMTOKEN #IMPLIED > 

<!ELEMENT UserEnvironment (EMPTY) > 

<!ATTLIST UserEnvironment 

Class NMTOKEN #IMPLIED 
ID PUBIDLITERAL #IMPLIED 
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Cacheabillty NMTOKEN #IMPLIED 
ValidityPeriod NMTOKEN #IMPLIED > 

<!ELEMENT StatusText (EMPTY) > 

5 

<!ATTLIST StatusText 

Class NMTOKEN #IMPLIED 
ID PUBIDUTERAL #IMPLIED 
10 Cacheability NMTOKEN #IMPLIED 

ValidityPeriod NMTOKEN #IMPLIED > 

<!ELEMENT Statuslmage (EMPTY) > 

15 <!ATTLIST Statuslmage 

Class NMTOKEN #IMPLIED 
ID PUBIDLITERAL #IMPLIED 
Cacheability NMTOKEN #IMPLIED 
20 ValidityPeriod NMTOKEN #IMPLIED 

ImageType NMTOKEN #IMPLIED > 

<!ELEMENT StatusSound (EMPTY) > 

25 <!ATTLIST StatusSound 

Class NMTOKEN #IMPLIED 
ID PUBIDLITERAL #IMPLIED 
Cacheability NMTOKEN #IMPLIED 
30 ValidityPeriod NMTOKEN #IMPLIED 

SoundType NMTOKEN #IMPLIED > 

<!ELEMENT MessagingCapabllities (EMPTY) > 

35 <!ATTLIST MessagingCapabilities 
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Class NMTOKEN #IMPLIED 
ID PUBIDLITERAL #IMPLIED 
Cacheabillty NMTOKEN #IMPLIED 
ValidityPeriod NMTOKEN #IMPLIED > 

5 

<!ELEMENT EmailClient (EMPTY) > 

<!ATTLIST EmailClientType 

10 Class NMTOKEN #IMPLIED 

ID PUBIDLITERAL #IMPLIED 
Cacheabllity NMTOKEN #IMPLIED 
ValidityPeriod NMTOKEN #IMPLIED > 

1 5 <!ELEMENT VoiceCallCapability (EMPTY) > 

<!ATTLIST VoiceCallCapability 

Class NMTOKEN #IMPLIED 
20 ID PUBIDLITERAL #IMPLIED 

Cacheability NMTOKEN #IMPLIED 
ValidityPeriod NMTOKEN #IMPLIED > 



25 



<!ELEMENT MultimediaCallCapabilities (EMPTY) > 
<!ATTLIST MultimediaCallCapabilities 



Class NMTOKEN #IMPLIED 
ID PUBIDLITERAL #IMPLIED 
30 Cacheability NMTOKEN #IMPLIED 

ValidityPeriod NMTOKEN #IMPLIED > 

<! ELEMENT UserPresenceltem (EMPTY) > 

35 <!ATTLIST UserPresenceltem 
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Class NMTOKEN #IMPLIED 
ID PUBIDLITERAL #IMPLIED 
Cacheability NMTOKEN #IMPLIED 
ValidityPeriod NMTOKEN #IMPLIED 
5 ExtRef PUBIDLITERAL #IMPLIED 

ExtRefChange NMTOKEN #IMPLIED > 

<!ELEMENT CllentType (EMPTY) > 

10 <!ATTLIST ClientType 

Class NMTOKEN #IMPLIED 
ID PUBIDLITERAL #IMPLIED 
Cacheability NMTOKEN #IMPLIED 
15 ValidityPeriod NMTOKEN #IMPLIED > 

<!ELEMENT ClientPresenceltem (EMPTY) > 

<!ATTLIST ClientPresenceltem 

20 

Class NMTOKEN #IMPLIED 
ID PUBIDLITERAL #IMPLIED 
Cacheability NMTOKEN #IMPLIED 
ValidityPeriod NMTOKEN #IMPLIED 
25 ContentChange NMTOKEN #IMPLIED > 

<!ELEMENT ExtPresence (EMPTY) > 

<!ATTLIST ExtPresence 

30 

Class NMTOKEN #IMPLIED 
ID PUBIDLITERAL #IMPLIED 
Cacheability NMTOKEN #IMPLIED 
ValidityPeriod NMTOKEN #IMPLIED 
35 ContentChange NMTOKEN #IMPLIED > 
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<!- End of DTD ~> 



It will be evident to those skilled in the art that as technology ad- 
vances, the inventive concept can be implemented in many different ways. 
5 Therefore the invention and its embodiments are not limited to the above exam- 
ples but may vary within the scope and spirit of the appended claims. 
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CLAIMS 

1 . A mobile messaging system comprising at least one client device 
and a server, wherein 

the client device comprises means for transmitting presence informa- 
5 tion as presence attributes to the server and means for receiving presence at- 
tributes from the server, said presence information being categorized by a 
plurality of presence attribute types identified by attribute name, and 

the server comprises means for maintaining presence information 
based on the received presence attributes, characterized in that 
10 the client device comprises means for adding a qualifier to a pres- 

ence attribute, the qualifier comprising one or more parameters specifying the 
use of the attribute, and 

the client device comprises means for processing a received pres- 
ence attribute according to the qualifier parameters in said received attribute. 

15 

2. A system according to claim 1, characterized in that 

the client device comprises means for specifying in the qualifier the 
presentation settings of the attribute, and 

the client device comprises means for presenting the received attrib- 
20 ute on the basis of the qualifier. 

3. A system according to claim 1, characterized in that 

• the client device comprises means for specifying in said qualifier the 
application to which the attribute should be addressed, and 
25 the client device comprises means for addressing the received attrib- 

ute to the application indicated by the qualifier. 



4. A system according to any one of the preceding claims, char- 
acterized in that 

30 the server comprises means for determining on the basis of the quali- 

fier whether to send the attribute to one or more client devices. 

5. A mobile messaging system comprising at least one client device 
and a server, wherein 

35 the client device comprises means for transmitting presence informa- 

tion as presence attributes to the server and means for receiving presence at- 
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tributes from the server, said presence information being categorized by a plu- 
rality of presence attribute types identified by attribute name, and 

the server comprises means for maintaining presence information 
based on received presence attributes, characterized in that 
5 the client device comprises means for composing a presence infor- 

mation attribute identified by a combination of an authorizes an attribute name 
and a qualifier, the authorizer specifying the body responsible for maintaining 
the attribute and the qualifier specifying the use of the attribute, 

the server comprises means for searching for an already stored at- 
10 tribute containing same identifiers as a received attribute and means for replac- 
ing said already stored attribute with said received attribute if the combination of 
identifiers of said received attribute is identical to that of said already stored at- 
tribute or otherwise adding said received attribute, and 

.the client device comprises means searching for an already stored at- 
15 tribute containing same identifiers as a received attribute and means for replac- 
ing said already stored attribute with said received attribute if the combination of 
identifiers of said received attribute is identical to that of said already stored at- 
tribute or otherwise adding said received attribute. 



20 6.A mobile messaging system according to any one of the preceding 

claims, characterised in that 

the presence attributes received from the client device by the server 
are stored in a database according to a publisher user in association with a 
presence group. 

25 

7. A mobile messaging system according to any one of the preceding 
claims, characterized in that 

each presence attribute is part of an item including an attribute name 
element and an attribute value. 

30 

8. A mobile messaging system according to claim 7, character- 
ize d in that 

said name element includes an authority string indicative of an au- 
thority responsible for keeping said name element and attribute value unique. 
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9. A mobile messaging system according to any one of the preceding 
claims, characterized in that 

a presence set comprises one or more presence attributes belonging 
to a single publisher role of a publisher user in association with a single pres- 
5 ence group. 

10. A mobile messaging system according to claim 9, character- 
ize d in that 

a user of said client device as a publisher is able to use said client 
10 device or more than one client device in more than one publisher role. 

1 1 . A mobile client device for mobile messaging system, said client 
device comprising 

means for transmitting presence information as presence attributes to 
15 a server, said presence information being categorized by a plurality of presence 
attribute types identified by attribute name, characterized in that said 
client device further comprises 

means for adding a qualifier to a presence attribute, the qualifier 
comprising one or more parameters specifying the use of the attribute. 

20 

12. A mobile client device for mobile messaging system, said client 
device comprising means for receiving presence attributes from a server, said 
presence information being categorized by a plurality of presence attribute types 
identified by attribute name 

25 characterized in that said client device further comprises 

means for adding a qualifier to a presence attribute, the qualifier 

comprising one or more parameters specifying the use of the attribute, and 

means for processing a received presence attribute according to the 

qualifier parameters in said received attribute. 

30 

13. A mobile client device for mobile messaging system, said client 
device comprising means for transmitting presence information as presence at- 
tributes to the server, and 

means for receiving presence attributes from the server, said pres- 
35 ence information being categorized by a plurality of presence attribute types 
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Identified by attribute name, characterized in that said client device fur- 
ther comprises 

means for composing a presence information attribute identified by a 
combination of an authorizer, an attribute name and a qualifier, the authorizer 
5 specifying the body responsible for maintaining the attribute and the qualifier 
specifying the use of the attribute, 

means for searching for an already stored attribute containing same 
identifiers as a received attribute, and 

means for replacing said already stored attribute with said received 
10 attribute if the combination of identifiers of said received attribute is identical to 
that of said already stored attribute or otherwise adding said received attribute. 

14. A mobile client device according to any one of the claims 11-13, 
characterized in that 

15 eacn Presence attribute is part of an item including an attribute name 

element and an attribute value. 



in that 



1 5. A mobile client device according to claim 14, characterized 



20 said name element includes an authority string indicative of an au- 

thority responsible for keeping said name element and attribute value unique. 

16. A mobile client device according to any one of the claims 11-15, 
characterized in that 

25 a Presence set comprises one or more presence attributes belonging 

to a single publisher ro/e of a publisher user in association with a single pres- 
ence group. 

1 7. A mobile client device according to claim 16, characterized 

in that 

30 a user of said mobile client device as a publisher is able to use said 

client device or more than one client device in more than one publisher role. 

18. A server for a mobile messaging system, said server comprising 
means for maintaining presence information based on received presence attrib- 

35 utes, said presence information being categorized by a plurality of presence at- 
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tribute types identified by attribute name, characterized in that said 
server further comprises 

means for searching for an already stored attribute containing same 

identifiers as a received attribute, and 
5 means for replacing said already stored attribute with said received 

attribute if the combination of identifiers of said received attribute is identical to 
that of said already stored attribute or otherwise adding said received attribute. 

19. A server according to claim 18, characterized in that 

10 the presence attributes received from a client device by the server is 

stored in a database according to a publisher user in association with a pres- 
ence group. 

20. A server according to claim 18 or 19, characterized in that 
15 each presence attribute is part of an item including an attribute name element 

and an attribute value. 

21 .A server according to claim 20, c h a r a c t e r i z e d in that 
said name element includes"an authority string indicative of an au- 
20 thority responsible for keeping said name element and attribute value unique. 

22. A server according to any one of the claims 18 - 21, charac- 
terized in that 

a presence set comprises one or more presence attributes belonging 
25 to a single publisher role of a publisher user in association with a single pres- 
ence group. 

23. A server according to claim 22, characterized in that 

a user of a client device in communication with said server acting as a 
30 publisher is able to use said client device or more than one client device in more 
than one publisher role. 

24. A presence system, comprising: 

at least one physical device having at least one presence client for 
35 enabling a presence user to interact with the system as a publisher or a sub- 
scriber; and 
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a server for maintaining valid values of presence sets of attributes of 
a publisher for access by subscribers according to associated presence groups. 

25. A presence system according to claim 24, c h a r a c t e r i z e d in 
5 that each attribute is part of an item including an attribute name element and an 

attribute value. 

26. A presence system according to claim 25, c h a r a c t e r i z e d in 
that said name element includes a qualifier having information related to attrib- 

10 ute usage. 

27. A presence system according to claim 26 .characterized in 
that said name element includes an authority string indicative of an authority re- 
sponsible for keeping said name element and attribute value unique. 



15 



20 



25 



28. A presence system according to any of the claims 24 - 27, 
characterized in that a presence set comprises one or more attributes 
belonging to a single publisher role in association with a single presence group. 

29. A presence system according to claim 28, c h a r a c t e r i z e d in 
that said user interacting with said system as a publisher is able to use said 
presence client or more than one presence client in more than one publisher 
role. 

30. A presence system according to claim 28, c h a r a c t e r i z e d in 
that each attribute is part of an item including an attribute name element an at- 
tribute value. 

31. A presence system according to any one of the claims 24 - 30, 
30 wherein said at least one physical device is a mobile physical device. 

32. A computer program embodied in a computer-readable medium 
for storage in a physical device, characterized in that 

the program is a presence client program for enabling a presence 
35 user to interact with a presence system as a publisher of at least one presence 
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set of attributes for access by one or more subscribers according to an associ- 
ated at least one presence group. 

33. The presence client program according to claim 32, c h a r a c - 
5 terized in that the program enables a presence user to interact with the 

presence system as a subscriber to at least one set of attributes associated with 
a presence group in which the subscriber is a member. 

34. The presence client program according to claim 32 or 33, 
10 characterized in that each attribute is part of an item including an attrib- 
ute name element and an attribute value. 

35. The presence client program according to claim 34, c h a r a c - 
terized in that said name element includes a qualifier having information re- 

15 lated to attribute usage. 

36. The presence client program according to claim 35, ch a ra c- 
terized in that said name element includes an authority string indicative of 
an authority responsible for keeping said name element and attribute value 

20 unique. 

37. The presence client program according to any one of the claims 
32 - 36, c h a r a c t e r i z e d in that a presence set comprises one or more at- 
tributes belonging to a single publisher role in association with a single presence 

25 group. 

38. The presence client program according to claim 37, c h a r a c - 

terized in that 

said user interacting with said system as a publisher is able to use 
30 said presence client program or more than one presence client program in more 
than one publisher role. 

39. The presence client program according to claim 37, c h a r a c - 
terized in that 

35 each attribute is part of an item including an attribute name element 

and an attribute value. 
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40. The presence client program according to any of the claims 32 - 
39, c h a r a c t e r i z e d in that the physical device is a mobile physical device. 

5 41. A physical device having a computer program embodied in a 

computer-readable medium stored therein, characterized in that the pro- 
gram is a presence client program according to any of the claims 32 - 40. 

42. A data structure embodied in a computer-readable medium for 
1 o storage in a physical device, characterized in that 

the data structure is a presence database for storing valid values of 
presence sets of attributes of one or more publishers for access by subscribers 
according to presence groups associated with said presence sets. 

15 43. A data structure according to claim 42, c h a r a c t e r i z e d in 

that 

each attribute is part of an item including an attribute name element 
and an attribute value. 

20 44 - A data structure according to claim 43, c h a r a c t e r i z e d in 

that 

said name element includes a qualifier having information related to 
attribute usage. 

25 45 - A data structure according to claim 44, characterized in 

that 

said name element includes an authority string indicative of an au- 
thority responsible for keeping said name element and attribute value unique. 

30 46 \ A data structure according to any of the claims 42 - 45, c h a r - 

acterized in that 

a presence set comprises one or more attributes belonging to a single 
publisher role in association with a single presence group. 

35 47 ■ A data structure according to any of the claims 42 - 46, c h a r- 

acterized in that 



BNSOOCID: <WO 020S39SSA 1 J_» 



WO 02/093959 



PCT/FI02/00403 



82 

a user interacting with said physical device as a publisher is able to 
use said data structure to publish more than one publisher role, each role having 
distinct presence sets in association with distinct presence groups. 

5 48. A data structure according to any of the claims 42 - 47, c h a r- 

a c t e r i z e d in that said physical device is a mobile device. 

49. A physical device having a data structure embodied in a com- 
puter-readable medium stored therein, characterized in that the data 
10 structure is a presence data structure according to any of the claims 42 - 48. 
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